[00:18] I have some questions on the PackagingGuide/Basic wiki page. [00:18] 1) a "rules" file is not needed for a package that not written in C/C++, right? [00:19] You *always* need a rules file. [00:19] 2) what the heck are postinst and prerm, and are they unique per package or always the same? [00:20] They are per-package scripts which are run after the package is installed (postinst) and before it is removed (prerm). [00:22] 2a) this page says nothing about postinst and prerm other than "copy them". If I'm building a package for a brand new app (which I am), how does that work? Should I copy these from another package and best-guess my way through it? [00:23] Yes. The commands below are saying to copy them out of the hello package. [00:24] You usually don't need prerm/preinst/postinst/postrm [00:25] You might find it easier to look at an existing package while you're reading this and matching up what it's doing with what the guide says. [00:26] broonie: can you recommend a simple package that is all, say, Python. I think that would help immensely. [00:26] Would anyone care to review http://revu.ubuntuwire.com/details.py?package=terminator, a python script for packing oodles of terminals into one window? (my first revu upload, so be gentle ;) [00:27] Ng: I'll take a look, as I'm interested on it ;) [00:27] \o/ [00:28] wolfger: A program or a module? For a program scons has fairly simple packaging (the program itself is a bit complicated but the packaging is simple) [00:28] Ng: You made a debian native package? [00:28] Ng: is there a good reason for it to be native? [00:28] I think upstream did it, right? [00:28] I thought he was upstream [00:28] * pochu installed that from the ppa :) [00:28] hmm, right :) [00:28] broonie: scons should work great, then. Thanks [00:29] Amaranth: pochu: I am upstream and the packager and it's in neither debian nor ubuntu atm, so that seemed like the right thing to do, but I'm happy to change it if not :) [00:30] It shouldn't be a native package [00:30] mmkay [00:30] Unless you think it's only useful in Ubuntu [00:30] Ng: you don't need debian/dirs [00:31] I'd make it priority: optional [00:31] Ng: by the way it looks promising [00:31] done and done [00:31] :) [00:31] I need to try the full-screen patch btw [00:32] broonie: apt-get source scons is giving me "no such file or directory" error :-( [00:32] pochu: I'm going to get another release out in the next few days with all of the latest goodness :) [00:32] (or you can grab from trunk ;) [00:34] Ng: Standards-Version > 3.7.3. Description - don't repeat in short description the package name. [00:34] * Ng nods [00:37] E: terminator_0.7_i386.changes: bad-distribution-in-changes-file gutsy [00:37] W: terminator: binary-without-manpage usr/bin/terminator [00:37] W: terminator: binary-without-manpage usr/bin/terminator [00:37] W: terminator: binary-without-manpage usr/bin/terminator [00:37] W: terminator: binary-without-manpage usr/bin/terminator [00:37] W: terminator: copyright-lists-upstream-authors-with-dh_make-boilerplate [00:37] W: terminator: binary-without-manpage usr/bin/terminator [00:37] W: terminator: copyright-lists-upstream-authors-with-dh_make-boilerplate [00:37] W: terminator: binary-without-manpage usr/bin/terminator [00:37] W: terminator: copyright-lists-upstream-authors-with-dh_make-boilerplate [00:38] woops :-( [00:38] Erk, pastebin. [00:38] * pochu blames his SSH connection [00:38] Distribution should be hardy... [00:38] Why so many of the same warnings? [00:39] Fujitsu: because my connection was lagging and I thought it was me not pressing mouse1 and mouse2 buttons at the same time ;) [00:40] with stuff like the distribution and the native package thing, should I change all of the changelog entries or just the most recent? [00:41] you should move the upstream changelog to ChangeLog, and leave debian/changelog for the packaging things [00:41] Ng: most recent [00:41] aha, on both counts [00:42] Ng: changing released stuff is usually not a great idea. audit, and all [00:42] in which case it's quite tempting to blow away debian/changelog entirely [00:42] Hobbsee: yeah, that's what I figured, but I'm not sure where the line is for stuff that's not really in a proper archive yet [00:43] true [00:43] usually you don't, anyway [00:44] Ng: you need to follow http://wiki.debian.org/DebianPython/NewPolicy . Basically choose either python-central or python-support, and add the right dependencies and XS-Python-Versions and XB-Python-Versions. [00:45] And add DEB_PYTHON_SYSTEM=pycentral (or pysupport) to the begin of debian/rules [00:48] Ng: look at the CDBS + distutils section in that page, and ignore the control.in thing. [00:52] pochu: ok. is one better/officialer? [00:53] Ng: Ubuntu prefers python-central as it's written by doko, but I don't think one is better [00:54] But pysupport should be ok too, so feel free to choose it. === asac_ is now known as asac [01:03] wolfger: scons is in universe\ [01:03] IIRC [01:09] broonie: well, it was complaining of a directory on my local not being found... I created that dir (archive.canonical.com_ubuntu_dists_gutsy_commercial_source_Sources) and now I get "E: Read error - read (21 Is a directory)" [01:10] so I've no idea what I've done wrong, or not done right [01:16] that's not supposed to be a directory, it's supposed to be a file; and you aren't supposed to create it, you're supposed to get it via apt-get update (directly or through one of the interfaces that wraps this functionality) [01:20] slangasek: okay, removed the directory I created, did sudo apt-get update then sudo apt-get source scons, and I still am getting the "no such file or directory" error [01:24] wolfger: surely you're getting some error output when you run apt-get update? [01:27] night [01:27] slangasek: right you are. Not sure why I didn't notice it [01:28] Failed to fetch http://archive.canonical.com/ubuntu/dists/gutsy/Release Unable to find expected entry commercial/binary-i386/Packages in Meta-index file (malformed Release file?) [01:36] wolfger: Can you pastebin your sources.list file? [01:37] StevenK: pastebin? [01:37] !pastebin [01:37] pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [01:40] StevenK: http://paste.ubuntu-nl.org/50222/ [01:40] heylo [01:45] hi zul [01:58] wolfger: It's partner, not commercial. [02:02] Fujitsu: you're saying I should change lines 47 and 48 from pastebing to say "partner"? [02:02] wolfger: Yes. [02:05] great. Thanks to everybody for their help. (those lines are throwbacks to Tribe 4 or Tribe 5 installation) [02:05] ls [02:05] hrm i was almost sure there was a svalib based rdesktop client [02:05] imbrandon: If there is, it needs to die. [02:06] heh [02:06] how else do you propose to use rdesktop without X ? [02:06] Why would you? [02:06] client or server? [02:06] client [02:07] imbrandon: im with Fujitsu on this one [02:07] imbrandon: framebuffer... [02:07] Fujitsu: ultra thinclient [02:09] imbrandon: well get cracking on one ;) [02:09] heh nah [02:09] got better things to do [02:10] xfbdev would probably work as well [02:10] If imbrandon learns how to code svgalib, I'll brain him myself [02:10] directFB would rock [02:10] lol [02:11] x11vnc would also be good [02:19] there is directvnc that, but no directrdp === bigon is now known as bigon` === harrison1 is now known as harrisony [03:20] * persia grumbles about latency: if REVU can feed me 3 streams at 140kps, it ought be able to feed me one stream at 420kps :( [03:20] heh [03:27] Is there a limit on package size? Is 534MB of source too much? [03:28] *ouch* [03:28] Some of the FPSes are huge, like sauerbraten. [03:28] Though that's only ~350MB, IIRC. [03:28] 534MB of *source code* [03:29] or is that data, binary stuff? [03:29] Fujitsu: That's what I was thinking. It's another game (I'm not yet sure if it's FPS). Nice graphics are good, but I wonder if we oughtn't have a policy to avoid a future import of a 7-CD set. [03:29] It is getting a bit iffy. That's a significant percentage of the current archive size. [03:30] sladen: 534MB of "source" for a -data package. I'm not sure what it contains yet, due to the annoyances of TCP ACK throttled connections. [03:30] moo. [03:31] am I loosing my mind or is my diff being retarded? [03:31] psusi: Likely a combination, but diagnosis is tricky without more context [03:31] diff foo foo-mine shows no changes, but diff foo/bar foo-mine/bar does [03:32] I'll go take a nap now. Please dig up some problems for me to fix once I get up. http://revu.tauware.de/details.py?package=malbolge [03:32] diff -r ? [03:32] psusi: diff -urN [03:32] there we go ;) [03:33] hehe... why on earth would it not recurse by default? heh [03:35] psusi: If it recursed by default there'd be no easy way to determine if two directories had the same set of files. [03:35] howso? [03:36] psusi: Currently diff foo/ bar/ tells you if foo/ and bar/ have a different set of files. If it recursed, it would instead tell you how the files in foo/ and bar/ differed. [03:37] huh? if it recursed by default then it would just tell you what files in their subdirs differed as well [03:38] if you don't care, either ignore those parts of the output or add a NOT recurse flag :) [03:38] psusi: Right, which would be useless when comparing two runs of a data collection tool to make sure the same set of samples was collected (when you expect to take a week or two to understand the differences) [03:41] hrm... now to remember how to dpatchify a package === jelmer is now known as JELMER [04:15] Ubulette: This is the first REVU day that mozilla-devscripts has been open for review (last week was canceled due to hardware issues). I'm reviewing it now. [04:17] persia, don't bother, i'm maintaining it elsewhere now (and i've made a new version - remember i'm the author) [04:17] Ubulette: OK. You sure you don't want to put a candidate up? I thought this would considerably simplify the maintenance of the mozilla packages. [04:18] it was my initial goal [04:20] but no review from here, and no sponsoring from asac despite his initial interest, so I asked for it to be nuked earlier today (well, yesterday now) [04:22] Ubulette: No review on REVU is just a matter of colliding against bad timing and a hardware failure. I've advocated it, as the package looks perfectly clean (although I've a couple nitpicks, easily addressed by a new revision). [04:22] On the other hand, if it's not useful to mozilla maintainers, I can re-archive it. Your call. [04:24] i've fixed a bug since i've posted it [04:24] and i've made 0.02 [04:24] with new features [04:24] Ubulette: Was 0.01 distributed widely? If not, perhaps no need to bump the version. [04:25] it was not [04:27] wtf? dpatch apply breaks if the patch file starts with a description? [04:27] psusi: Only if the description isn't formatted according to dpatch rules. [04:28] why does it have special rules and where are those listed? [04:28] psusi: To differentiate it from comments as part of a patch, and in the manual page. [04:29] persia, ok, i'll try once again that revu thing. i've pushed 0.02 [04:29] (man -S7 patch, in case that isn't clear) [04:29] s/patch/dpatch/ [04:30] Ubulette: Thanks. I've a couple in queue, but will hit it again in an hour or two. [04:30] persia: the man page doesn't appear to mention this, and what do you mean "to differentiate it from comments as part of the patch"? patch already understands they are comments [04:30] psusi: To differentiate patch comments from dpatch comments. Read DPATCH(7) [04:31] ahh... other section of the manual... [04:32] ahhh, that's why... the patch file is supposed to be a script [04:32] first line needs to be a patch shbang [04:33] psusi: Consider dpatch-edit-patch to avoid confusion [04:34] already worked on the code, now just breaking it out into patches [04:36] psusi: That makes it easy. Make a monolithic patch. Break it out with filterdiff. Apply the broken out patches individually with dpatch-edit-patch. [04:38] hrm... filterdiff eh? I usually just use emacs in diff mode [04:39] psusi: That works too :) [05:17] Ubulette: Thanks. Let me know when it's done, and I'll hit it next (as this is the right channel - oops :) ) [05:17] Ah. Changelog should have all the entries, so you if you want this to be 0.2, you should also have the 0.1 changelog, and describe the differences for 0.2 [05:18] debian changelog or upstream ? [05:18] Ubulette: Since you want this to be a native package, they are the same (part of why I don't like native packages). [05:18] debian changelog is supposed to contain only versions that has been posted, right ? [05:19] Ubulette: Ideally, which is why I suggest this should still be 0.1, as it hasn't been widely distributed. [05:33] persia, could I push 0.01 on top of 0.02 ??? [05:33] Ubulette: Sure. REVU doesn't care about versions. [05:34] done [05:35] brb [05:36] o/c [05:36] ugh [05:43] persia, http://revu.tauware.de/details.py?upid=1115 [05:43] Ubulette: Great. It's next in my queue (unless someone else gets it first) [05:44] thx. going to sleep. need stamina for tonight [05:56] Oh, it's REVU day again? [05:56] minghua: Every Monday (barring hardware issues). [05:57] there are hardware issues [05:58] nixternal: Not today :) [05:58] amd64 and i386 seem to be working fine, but not everything else [05:58] I have been building kde4 all night long [05:58] chroot problems according to the logs [05:59] Right, powerpc and sparc are waiting on infinity. [05:59] nixternal: Ah. That's archive problems, not REVU problems (but still annoying). [05:59] oh, revu hardware problems :) [05:59] ya, I would definitely hurry up now that you said that, possibly a jinx [05:59] nixternal: Right. Last week there was an overheating issue, now resolved. [06:00] ugh [06:00] hahahhaa [06:00] overheating.... persia slow down on the reviewing then if you are overheating it [06:03] how the hell could someone upload a damn package, when the names of the patches in the series file were not the same as the patches in directory? [06:03] it keeps failing to build, but somehow, someway, someone did it [06:03] nixternal: dput [06:04] Ubulette: advocated. I'm still unhappy about native w/upstream changelog, etc., but this is pointless nitpicking. [06:04] Anyone have a package waiting for REVU, before I go back to FIFO processing? [06:05] persia: well ya, but the packages built in the buildd's just fine [06:05] nixternal: Shouldn't be a big issue. If there are patches not referenced in the series file, those patches don't get applied. Of course, that doesn't explain why it FTBFS for you. [06:06] hrmm, there were patches referenced in the series file, but they weren't in the patches directory [06:06] well they were, but the names were different [06:07] anywho, fixed the ftbfs, but still weird [06:07] food time [06:10] ember: somerville32: Vorian: Please consider submitting your updated packages to the U-U-S queue. They are likely good fixes, and may be being ignored on REVU. [06:11] persia, ok [07:26] persia: should the webapps package I upload be built as source package? === Ibalon is now known as zakame [07:34] liri: Every package that enters the archive must enter as a source package. The source package then generates one or more binary packages for installation on user systems. In the case of a webapps package, these "binary" packages frequently contain the source of the web application for interpretation by the framework. [07:35] Separately, I don't really know that much about web application packaging: you'll do better to ask the channel generally, as you might get an answer from someone who actually knows the subject about which they write. [08:13] Could someone on i386 or powerpc please check to see if livemix on REVU segfaults a lot? The packaging looks clean, and the package works for me, except segfaulting most of the time. If it's architecture-specific, this should be a bug, rather than blocking upload. [08:13] Is there any package in Gutsy that uses the homepage header? [08:13] cyberix: the Homepage: header wasn't supported in Gutsy. [08:14] Oh [08:14] persia: alright. I was just wondering how would I go about packaging a webapps (collection of scripts) package as source package [08:15] Maybe I could contact a maintainer of a webapps package from the Ubuntu packages list [08:15] liri: Understood. I'm just not the right person to answer that. You might look at one of the existing webapp packages in the repository as an example. [08:15] persia: The linda/lintian minus/hyphen warning for malbolge package looks like a false alarm to me. [08:15] liri: Or just take a look at an example, and ask specific questions here. [08:15] cyberix: It's not. I checked the manpage source. [08:16] persia: But it is part of a filename. [08:17] cyberix: In which case you want to use \- as otherwise copy & paste will fail. [08:17] oh [08:17] man renders - as a hyphen? [08:18] cyberix: I forget which is the default behaviour, but not specifying a minus means that your manpage might break if that behaviour ever differs for any reason. Using \- means it will always work. [08:19] persia: well, I'm wondering how/where to put the scripts for the source package? should the .diff generated contain those scripts also or only the debian/ directory? [08:20] persia: I was thinking about looking at other source packages but I'm unable to conclude how they got build in the first place (in terms of what to put where...) [08:21] liri: I don't have enough context to understand what you mean. Typically, the contents of the package that are to be packaged belong in ./ and the description of the packaging belongs in ./debian/. The diff.gz contains any modifications not included upstream, along with the ./debian/ directory. The building takes place according to the instructions in debian/rules. [08:23] persia: I probably need someone experienced with webapps packaging to work on this with me [08:24] liri: That sounds likely. You might send an email to ubuntu-motu-mentors@lists.ubuntu.com with a description of what you are trying to accomplish, a link to your work in progress, and a description of the problem you are encountering. [08:25] What is this webapp? Is it written in PHP? Does upstream follow the usual PHP-upstream theory of not releasing security updates? Should I scream? [08:25] Fujitsu: php indeed. [08:27] persia: Are we allowed to reject packages on the basis that they have lots of security holes and upstream is insane with regard to releasing patches for them? [08:27] liri: Are you upstream? [08:27] persia: yes. I'm the author of the software [08:27] Because I'd like such a guideline, even if it doesn't apply here. [08:28] Fujitsu: Yes, as long as we can show we spoke with upstream to demonstrate that. [08:28] liri: Great. If you can convince Fujitsu you will support security updates, I suspect he may be able to point you to an example or two :) [08:29] persia: I'd love that, all in all it is in my personal interest to keep my software secured more than it is Fujitsu's :) [08:29] Fujitsu: More generally, any software with multiple RC issues (including open security problems) that upstream can not / will not / does not address becomes a candidate for removal. [08:29] Fujitsu: would you need to review the code? [08:29] Basically, does it have a Wordpress- or phpMyAdmin-like security track record? [08:32] Fujitsu: I'm not aware of wordpress or phpmyadmin's security track record [08:32] Well, WordPress has had approximately 50 CVEs in the past 18 months. [08:32] And they don't normally release patches for each issue. [08:33] Fujitsu: well I haven't received any emails yet regarding security (the community around it is still growing but it's not close to being anything like wordpress/phpmyadmin users base) [08:34] Fujitsu: you could go over websvn, I'd really appreciate every comment on security and will do my best to attend to it [08:34] * Fujitsu generally likes to avoid PHP. [08:35] What's the name of the project? [08:35] Fujitsu: daloradius [09:24] guys im adding a little .desktop file to SearchandRescue, only problem is I cant remmeber where it goes, in the root of /debian? [09:33] wraund: It goes upstream. If it can't go there, it goes in debian/ [09:38] persia: good good :) === LucidFox is now known as LucidFox_KOTOR24 [10:01] License Question: Does "... any distribution of the object code of the Software in a physical product must provide you the right to access and modify the source code for the Software and to reinstall that modified version of the Software in object code form on the same physical product on which you received it." mean that the code can only be distributed on rewritable media? [10:03] Huh, sounds like so. Is that from GPL v3? :-P [10:03] minghua: No, from some annoying Red Hat "supplementary conditions" file. I suspect even Fedora doesn't comply with that licensing. [10:04] persia: Oh, and you can distribute it on flash disks, too. (Sorry to be pedantic, but couldn't resist. :-) [10:04] minghua: is not "rewritable media" a superset including "flash disks"? [10:05] persia: Hmm. Perhaps. Sorry. [10:05] minghua: No need to be sorry. I am a confirmed pendant. If you correct me (correctly), I am happier :) [10:06] persia: That is a really strange license. [10:07] Fujitsu: Yep. There's also a special note that the United Nations Convention on the International Sales of Goods shall not apply, which I'm trying to understand. I'm suspecting it's a multiverse candidate, which is funny, as ttf-liberation is supposed to replace a different multiverse candidate. [10:07] How very liberated. [10:08] Well, it at least allows people to play the "Yes, I wish to exchange overlords, please" card. [10:08] I guess. [10:09] What's the alternative? Some Microsoft core font? [10:09] Fujitsu: Yep. Arial, Courier, and Times New Roman. [10:10] Ah, old. [10:10] old? [10:10] Haven't they all been replaced? [10:11] Do you mean by Vera? [10:11] I suspected it would be liberation fonts. Debian-legal seems to think it's non-free material, though I admit not having read the actual discussions. [10:11] No, the new Microsoft C* [10:12] Fujitsu: No idea. I don't really follow Microsoft fonts. [10:12] Fujitsu: Liberation has the same metrics (height, width) as the MS web core fonts. The Vera/DejaVu fonts don't. [10:12] Sorry, that should be for persia. [10:13] minghua: Ahh. [10:13] minghua: Right. Still, it's just an overlord exchange in my book. [10:13] Then again, the C* fonts probably don't have the same metrics as corefonts either. [10:13] Why do they have such a deranged license? [10:13] So people will still use those for web pages. [10:14] Redhat would be a more benevolent overlord than MS, I assume. :-) [10:14] One would hope so. [10:15] * persia doesn't know. MS labs does good stuff, and their open code tends to be nice. The fonts concerned have been free-as-in-beer for years. === LucidFox_KOTOR24 is now known as LucidFox [10:19] persia: Only because their original license didn't forbid redistribution. You can no longer download them from MS website. [10:19] Well, the bit about the UN convention on international sale of goods appears to indicate that US law applies to these fonts, rather than the law in the location where the fonts are to be used, and not have any other impact. I guess it's just the rewritable media bit that makes it multiverse. [10:20] minghua: Sure. Upstream abandons stuff sometimes. When it's useful, it gets mirrored. [10:21] * minghua doesn't think it's that simple. [10:22] minghua: Why not? How is Microsoft any different than any other corporate upstream? [10:22] Those fonts, at least Times New Roman, are still installed by default and widely used in Windows system interface in XP. So I wouldn't call it "abandoned". But they stopped downloads on their websites long before that. [10:23] minghua: Ah. Upstream closed newer revisions. I think we've a few other packages like that in the archive. [10:24] persia: Right. My impression is, MS distributed those fonts to get domination on web page font usage, and pull the carpet once it gets the dominant position. [10:24] I'm sure someone in MS regretted allowing redistribution of those fonts. [10:24] minghua: Sure. Didn't bittorrent do that recently? Doesn't make the old version bad. [10:25] persia: The old version isn't bad (I like MS corefonts), the company is (Bittorrent is becoming bad IMHO, too). [10:26] persia: Wait, how is it even multiverse, with a nasty redistribution restriction? [10:26] minghua: I don't disagree with that, I just don't see how having competing free-as-in-beer fonts makes any difference. [10:27] minghua: Only becoming bad? [10:27] Fujitsu: Mostly for PR, I'd guess. I'd rather a complete repack without using the RedHat trademark, but wouldn't be surprised to see it appear, regardless of what I post to REVU. [10:28] persia: The rewriteability requirement would exclude it from multiverse, wouldn't it? [10:28] persia: To be fair, MS corefonts' license is much more restrictive. [10:29] Fujitsu: I am not really following the bittorrent company story. [10:29] Fujitsu: Depends on how you interpret it. Clause 1b in the addendum in http://revu.ubuntuwire.com/revu1-incoming/ttf-liberation-0712210130/ttf-liberation-0.2/debian/copyright only appears to apply to physical products. [10:30] persia: Even so. Isn't multiverse meant to be safe to distribute regardless of medium? [10:30] ie. I can burn a CD? [10:31] Fujitsu: There's lots of stuff in there that's not safe to distribute without conditions. Especially stuff that cannot be sold. I'm not sure if we require the ability to distribute non-rewritable optical discs. Ask elmo. [10:31] For personal use, burning a CD is perfectly fine: you just can't distribute that CD. [10:31] Hmm. [10:32] It still seems particularly nasty. I really don't like it. [10:32] But I defer to elmo. [10:32] Fujitsu: I don't like it either, but I don't feel it's my place to make the decision. I didn't like pq either (and still don't). [10:33] That ended up going in, didn't it? :( [10:33] Yes. It is now in the archives. Further, it is in the archives for an LTS, so we have to hope upstream supports it for security & bugfixes until April 2013. [10:34] Um, yeah, yay. [10:34] * persia doubts upstream will still be active then [10:34] Shall I find another 50,000 or so beer-free Windows apps now? [10:34] They should be accepted, so I'd better get busy on them. [10:35] Fujitsu: I'd prefer you waited for hardy+1 to upload them all. I'm afraid that such controversy would adversely impact LTS preparation. [10:35] Quite possibly. But we've just made a nasty step down a very long, steep, slippery slope. [10:36] Yes. I'd actually like to see the 50,000 free-as-in-beer apps submitted to multiverse in hardy+1 (all with runtime dependencies on wine). [10:36] lol [10:36] CheGuevara: The point would be to point out the absurdity of current policy, not to actually have them included. [10:37] Was policy ever discussed after mdz (I think?) provided his opinion? [10:38] Fujitsu: No, and it was elmo to whom the decision was delegated (although mdz did express an opinion) [10:38] Can't we have a MOTU meeting and block such situations again? [10:38] Right, I forget exactly. [10:38] Not directly. MOTU Meeting can raise an issue to MC who can raise it to TB, but MOTU Meeting cannot override TB. [10:40] Surely we can impose additional restrictions on multiverse licensing, or at least on new packages, without an official TB stance change? [10:40] If not, I guess we must convince the TB. [10:40] persia: yeah i figured :P [10:41] Fujitsu: Some subset of us can agree not to upload such packages to multiverse, but only MC decision is binding for all MOTUs, and only TB decision is binding for all ubuntu-dev. [10:41] * persia notes that MC tends to follow MOTU best practice recommendations, and TB tends to follow MC recommendations in most cases [10:46] apachelogger_: ping [10:46] hellboy195: pong [10:46] * persia dislikes virtual table tennis [10:47] apachelogger_: KMuddy is a MUD client for KDE desktop environment --> http://en.wikipedia.org/wiki/MUD [10:48] hellboy195: yeah, already got a description, thanks :) [10:48] apachelogger_: ok, np [10:50] apachelogger_: from your list I only know 2 by name. I only tried out Jahshaka [10:51] jashaka is like totally over the top [10:51] * apachelogger_ didn't manage to use it [10:51] Fujitsu: Hmm, how can a slope be bother very long and very steep? :-) [10:52] minghua: It just needs to be very large. [10:52] You mean very deep? [10:53] ... or very tall, depending on the perspective ... [10:53] minghua: Yes. [10:54] apachelogger_: because? too complicated or b0rken? [10:54] hellboy195: too complicate [10:54] Does anyone have a strong opinion about $(MAKE) -j $(NCPUS) in debian/rules? [10:55] apachelogger_: mostly when something is too complicate it's fucking powerful but yeah I also worked with it a long time .. :) [10:56] hellboy195: powerful != bad usability [10:57] !language | hellboy195 [10:57] hellboy195: Please watch your language and topic to help keep this channel family friendly. [10:57] persia: No idea. Although I'm aware of the existence of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209008 [10:57] Debian bug 209008 in debian-policy "debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS" [Wishlist,Open] [10:57] persia: sry :( [10:58] apachelogger_: but often xD for me ... [10:58] minghua: Thanks. I guess it's policy-in-transition, so I shan't worry about it now. [11:17] apachelogger_: work for you. If you are interested ^^ https://bugs.edge.launchpad.net/ubuntu/+bug/179528 [11:17] Launchpad bug 179528 in ubuntu "[needs-packaging] Kalva " [Undecided,New] [11:26] hellboy195: looks interesting [11:27] apachelogger_: :) [11:36] 5 packages are now awaiting second advocates (and 20 waiting for a first advocate). Please trim the list at http://revu.ubuntuwire.com/ [12:16] superm1: Is there any documentation on the nature of the apparently massive changes to /etc/lirc/hardware.conf? [12:22] hey everyone [12:23] i've gotten feedback on a few packages of mine, but as I'm new to this i need clarification on a few terms, when the commenter states "Please update to a new debhelper compatibility version. ’5’ is the current standard. " is this referring to the Standards-Version line in debian/control? [12:23] jscinoz: Create a file called debian/compat containing the single character '5' [12:24] jscinoz: it's refering to the debian/compat file [12:24] oh thanks :) [12:24] also. [12:25] jscinoz: and also to the Build-Depends line, then you should B-D on debhelper (>= 5) too [12:25] yeah i have the build dependso ne [12:25] one* [12:25] jscinoz: and you might need to adjust your debian/*.install files [12:26] also, i have left over .svn directories in many subfolders of my source package, the commenter mentions running svn export when "preparing the tarball" is this done in the debian/rules file or manually? [12:26] jscinoz: this is done when creating the upstream tarball (or orig tarball) [12:26] ah :P [12:26] late on new years eve here bit sleepy :P === thekorn_ is now known as thekorn === asac_ is now known as asac [12:46] What is "a watch file to collect new upstream sources"? [12:49] cyberix: See uscan(1) [12:52] Does anyone feel like reviewing http://revu.tauware.de/details.py?package=apt-mark-sync? :-) It’s a program to synchronize the ”automatically/manually installed” status of packages between apt, aptitude, debfoster and deborphan. I believe i have fixed the issues pointed out in the previous reviews. Also, it would be nice to get a second person to advocate http://revu.tauware.de/details.py?package=hardware-connected, a program that indicates whether ... [12:53] ... given hardware exists in the system (intended for scripting). [12:55] ion_: You should really complain to upstream about the upstream version sequencing. It's very surprising. [12:56] persia: A lot of software seems to do that, e.g. compiz. But ok, i’ll do a 0.0.1 release. A moment... [12:56] ion_: No big rush. If the next upstream is 0.0.1, I'm happy :) [12:58] ion_: apt-mark-sync advocated. Nice clean-up job. [12:59] Ok, thanks [12:59] I’ll use 0.0.1 as the next release, then. [13:00] ion_: Thanks. Assuming your package is wildly popular, it will reduce the number of people who complain that we're shipping an outdated VCS snapshot. === bigon` is now known as bigon [13:13] Is there a place to request Tango-style icons? [13:16] is an packagename_version.orig.tar.gz required if the package has never been packaged on debian/ubuntu before? [13:16] LucidFox: iirc ``Cube asked in #launchpad which projects needs an (tango) icon [13:17] jscinoz: yes, that's the upstream source from which the deb gets build in the end [13:18] alright, if the only available source of the package is contained in a zip, should i extract and put the original source in a tar.gz [13:19] yes [13:20] ok [13:20] also.. [13:21] if i have made man pages for the binaries in my packages. should i have the debian/rules script gzip them? or have them already gzip'd and just copied to the appropriate location? [13:21] jscinoz: dh_compress does this for you [13:22] i'll look up how to use it, thanks :) [13:23] jscinoz: if you use CDBS for packaging its already done for you automatically [13:24] im just using plain old debhelper, with scripts i've scavenged and reworked from similar packages :P [13:25] jscinoz: then just make sure you call dh_compress in the appropriate targets in the correct place [13:27] thanks :) [13:27] So, can I find an example watch file for a Launchpad project somewhere? [13:34] yeah i need an example watch file too :P [13:34] There are a few examples of watch files in the uscan manual page. There might be another LP hosted project on REVU... [13:35] cheers [13:35] uscan man page had what i needed to know [13:37] Bah. I saw one recently, but can't find it on REVU. Apologies. === asac__ is now known as asac [13:39]