[00:18] <wolfger> I have some questions on the PackagingGuide/Basic wiki page.
[00:18] <wolfger> 1) a "rules" file is not needed for a package that not written in C/C++, right?
[00:19] <broonie> You *always* need a rules file.
[00:19] <wolfger> 2) what the heck are postinst and prerm, and are they unique per package or always the same?
[00:20] <broonie> They are per-package scripts which are run after the package is installed (postinst) and before it is removed (prerm).
[00:22] <wolfger> 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] <broonie> Yes. The commands below are saying to copy them out of the hello package.
[00:24] <pochu> You usually don't need prerm/preinst/postinst/postrm
[00:25] <broonie> 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] <wolfger> broonie: can you recommend a simple package that is all, say, Python. I  think that would help immensely.
[00:26] <Ng> 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] <pochu> Ng: I'll take a look, as I'm interested on it ;)
[00:27] <Ng> \o/
[00:28] <broonie> 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] <Amaranth> Ng: You made a debian native package?
[00:28] <pochu> Ng: is there a good reason for it to be native?
[00:28] <pochu> I think upstream did it, right?
[00:28] <Amaranth> I thought he was upstream
[00:28]  * pochu installed that from the ppa :)
[00:28] <pochu> hmm, right :)
[00:28] <wolfger> broonie: scons should work great, then. Thanks
[00:29] <Ng> 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] <Amaranth> It shouldn't be a native package
[00:30] <Ng> mmkay
[00:30] <Amaranth> Unless you think it's only useful in Ubuntu
[00:30] <pochu> Ng: you don't need debian/dirs
[00:31] <pochu> I'd make it priority: optional
[00:31] <pochu> Ng: by the way it looks promising
[00:31] <Ng> done and done
[00:31] <Ng> :)
[00:31] <pochu> I need to try the full-screen patch btw
[00:32] <wolfger> broonie: apt-get source scons is giving me "no such file or directory" error :-(
[00:32] <Ng> pochu: I'm going to get another release out in the next few days with all of the latest goodness :)
[00:32] <Ng> (or you can grab from trunk ;)
[00:34] <pochu> Ng: Standards-Version > 3.7.3. Description - don't repeat in short description the package name.
[00:34]  * Ng nods
[00:37] <pochu> E: terminator_0.7_i386.changes: bad-distribution-in-changes-file gutsy
[00:37] <pochu> W: terminator: binary-without-manpage usr/bin/terminator
[00:37] <pochu> W: terminator: binary-without-manpage usr/bin/terminator
[00:37] <pochu> W: terminator: binary-without-manpage usr/bin/terminator
[00:37] <pochu> W: terminator: binary-without-manpage usr/bin/terminator
[00:37] <pochu> W: terminator: copyright-lists-upstream-authors-with-dh_make-boilerplate
[00:37] <pochu> W: terminator: binary-without-manpage usr/bin/terminator
[00:37] <pochu> W: terminator: copyright-lists-upstream-authors-with-dh_make-boilerplate
[00:37] <pochu> W: terminator: binary-without-manpage usr/bin/terminator
[00:37] <pochu> W: terminator: copyright-lists-upstream-authors-with-dh_make-boilerplate
[00:38] <pochu> woops :-(
[00:38] <Fujitsu> Erk, pastebin.
[00:38]  * pochu blames his SSH connection
[00:38] <Fujitsu> Distribution should be hardy...
[00:38] <Fujitsu> Why so many of the same warnings?
[00:39] <pochu> Fujitsu: because my connection was lagging and I thought it was me not pressing mouse1 and mouse2 buttons at the same time ;)
[00:40] <Ng> 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] <pochu> you should move the upstream changelog to ChangeLog, and leave debian/changelog for the packaging things
[00:41] <Hobbsee> Ng: most recent
[00:41] <Ng> aha, on both counts
[00:42] <Hobbsee> Ng: changing released stuff is usually not a great idea.  audit, and all
[00:42] <Ng> in which case it's quite tempting to blow away debian/changelog entirely
[00:42] <Ng> 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] <Hobbsee> true
[00:43] <Hobbsee> usually you don't, anyway
[00:44] <pochu> 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] <pochu> And add DEB_PYTHON_SYSTEM=pycentral (or pysupport) to the begin of debian/rules
[00:48] <pochu> Ng: look at the CDBS + distutils section in that page, and ignore the control.in thing.
[00:52] <Ng> pochu: ok. is one better/officialer?
[00:53] <pochu> Ng: Ubuntu prefers python-central as it's written by doko, but I don't think one is better
[00:54] <pochu> But pysupport should be ok too, so feel free to choose it.
[01:03] <broonie> wolfger: scons is in universe\
[01:03] <broonie> IIRC
[01:09] <wolfger> 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] <wolfger> so I've no idea what I've done wrong, or not done right
[01:16] <slangasek> 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] <wolfger> 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] <slangasek> wolfger: surely you're getting some error output when you run apt-get update?
[01:27] <pochu> night
[01:27] <wolfger> slangasek: right you are. Not sure why I didn't notice it
[01:28] <wolfger> 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] <StevenK> wolfger: Can you pastebin your sources.list file?
[01:37] <wolfger> StevenK: pastebin?
[01:37] <StevenK> !pastebin
[01:37] <ubotu> 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] <wolfger> StevenK: http://paste.ubuntu-nl.org/50222/
[01:40] <zul> heylo
[01:45] <wolfger> hi zul
[01:58] <Fujitsu> wolfger: It's partner, not commercial.
[02:02] <wolfger> Fujitsu: you're saying I should change lines 47 and 48 from pastebing to say "partner"?
[02:02] <Fujitsu> wolfger: Yes.
[02:05] <wolfger> great. Thanks to everybody for their help. (those lines are throwbacks to Tribe 4 or Tribe 5 installation)
[02:05] <wolfger> ls
[02:05] <imbrandon> hrm i was almost sure there was a svalib based rdesktop client
[02:05] <StevenK> imbrandon: If there is, it needs to die.
[02:06] <imbrandon> heh
[02:06] <imbrandon> how else do you propose to use rdesktop without X ?
[02:06] <Fujitsu> Why would you?
[02:06] <Daviey> client or server?
[02:06] <imbrandon> client
[02:07] <zul> imbrandon: im with Fujitsu on this one
[02:07] <Daviey> imbrandon: framebuffer...
[02:07] <imbrandon> Fujitsu: ultra thinclient
[02:09] <zul> imbrandon: well get cracking on one ;)
[02:09] <imbrandon> heh nah
[02:09] <imbrandon> got better things to do
[02:10] <imbrandon> xfbdev would probably work as well
[02:10] <StevenK> If imbrandon learns how to code svgalib, I'll brain him myself
[02:10] <Daviey> directFB would rock
[02:10] <imbrandon> lol
[02:11] <Daviey> x11vnc would also be good
[02:19] <imbrandon> there is directvnc that, but no directrdp
[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] <imbrandon> heh
[03:27] <persia> Is there a limit on package size?  Is 534MB of source too much?
[03:28] <Fujitsu> *ouch*
[03:28] <Fujitsu> Some of the FPSes are huge, like sauerbraten.
[03:28] <Fujitsu> Though that's only ~350MB, IIRC.
[03:28] <sladen> 534MB of *source code*
[03:29] <sladen> or is that data, binary stuff?
[03:29] <persia> 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] <Fujitsu> It is getting a bit iffy. That's a significant percentage of the current archive size.
[03:30] <persia> 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] <sladen> moo.
[03:31] <psusi> am I loosing my mind or is my diff being retarded?
[03:31] <persia> psusi: Likely a combination, but diagnosis is tricky without more context
[03:31] <psusi> diff foo foo-mine shows no changes, but diff foo/bar foo-mine/bar does
[03:32] <cyberix> 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] <sladen> diff -r ?
[03:32] <persia> psusi: diff -urN
[03:32] <psusi> there we go ;)
[03:33] <psusi> hehe... why on earth would it not recurse by default? heh
[03:35] <persia> 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] <psusi> howso?
[03:36] <persia> 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] <psusi> huh?  if it recursed by default then it would just tell you what files in their subdirs differed as well
[03:38] <psusi> if you don't care, either ignore those parts of the output or add a NOT recurse flag :)
[03:38] <persia> 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] <psusi> hrm... now to remember how to dpatchify a package
[04:15] <persia> 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] <Ubulette> persia, don't bother, i'm maintaining it elsewhere now (and i've made a new version - remember i'm the author)
[04:17] <persia> 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] <Ubulette> it was my initial goal
[04:20] <Ubulette> 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] <persia> 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] <persia> On the other hand, if it's not useful to mozilla maintainers, I can re-archive it.  Your call.
[04:24] <Ubulette> i've fixed a bug since i've posted it
[04:24] <Ubulette> and i've made 0.02
[04:24] <Ubulette> with new features
[04:24] <persia> Ubulette: Was 0.01 distributed widely?  If not, perhaps no need to bump the version.
[04:25] <Ubulette> it was not
[04:27] <psusi> wtf?  dpatch apply breaks if the patch file starts with a description?
[04:27] <persia> psusi: Only if the description isn't formatted according to dpatch rules.
[04:28] <psusi> why does it have special rules and where are those listed?
[04:28] <persia> psusi: To differentiate it from comments as part of a patch, and in the manual page.
[04:29] <Ubulette> persia, ok, i'll try once again that revu thing. i've pushed 0.02
[04:29] <persia> (man -S7 patch, in case that isn't clear)
[04:29] <persia> s/patch/dpatch/
[04:30] <persia> Ubulette: Thanks.  I've a couple in queue, but will hit it again in an hour or two.
[04:30] <psusi> 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] <persia> psusi: To differentiate patch comments from dpatch comments.  Read DPATCH(7)
[04:31] <psusi> ahh... other section of the manual...
[04:32] <psusi> ahhh, that's why... the patch file is supposed to be a script
[04:32] <psusi> first line needs to be a patch shbang
[04:33] <persia> psusi: Consider dpatch-edit-patch to avoid confusion
[04:34] <psusi> already worked on the code, now just breaking it out into patches
[04:36] <persia> 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] <psusi> hrm... filterdiff eh?  I usually just use emacs in diff mode
[04:39] <persia> psusi: That works too :)
[05:17] <persia> Ubulette: Thanks.  Let me know when it's done, and I'll hit it next (as this is the right channel - oops :) )
[05:17] <persia> 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] <Ubulette> debian changelog or upstream ?
[05:18] <persia> 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] <Ubulette> debian changelog is supposed to contain only versions that has been posted, right ?
[05:19] <persia> Ubulette: Ideally, which is why I suggest this should still be 0.1, as it hasn't been widely distributed.
[05:33] <Ubulette> persia, could I push 0.01 on top of 0.02 ???
[05:33] <persia> Ubulette: Sure.  REVU doesn't care about versions.
[05:34] <Ubulette> done
[05:35] <imbrandon> brb
[05:36] <TheMuso> o/c
[05:36] <TheMuso> ugh
[05:43] <Ubulette> persia, http://revu.tauware.de/details.py?upid=1115
[05:43] <persia> Ubulette: Great.  It's next in my queue (unless someone else gets it first)
[05:44] <Ubulette> thx. going to sleep. need stamina for tonight
[05:56] <minghua> Oh, it's REVU day again?
[05:56] <persia> minghua: Every Monday (barring hardware issues).
[05:57] <nixternal> there are hardware issues
[05:58] <persia> nixternal: Not today :)
[05:58] <nixternal> amd64 and i386 seem to be working fine, but not everything else
[05:58] <nixternal> I have been building kde4 all night long
[05:58] <nixternal> chroot problems according to the logs
[05:59] <Fujitsu> Right, powerpc and sparc are waiting on infinity.
[05:59] <persia> nixternal: Ah.  That's archive problems, not REVU problems (but still annoying).
[05:59] <nixternal> oh, revu hardware problems :)
[05:59] <nixternal> ya, I would definitely hurry up now that you said that, possibly a jinx
[05:59] <persia> nixternal: Right.  Last week there was an overheating issue, now resolved.
[06:00] <imbrandon> ugh
[06:00] <nixternal> hahahhaa
[06:00] <nixternal> overheating.... persia slow down on the reviewing then if you are overheating it
[06:03] <nixternal> 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] <nixternal> it keeps failing to build, but somehow, someway, someone did it
[06:03] <persia> nixternal: dput
[06:04] <persia> Ubulette: advocated.  I'm still unhappy about native w/upstream changelog, etc., but this is pointless nitpicking.
[06:04] <persia> Anyone have a package waiting for REVU, before I go back to FIFO processing?
[06:05] <nixternal> persia: well ya, but the packages built in the buildd's just fine
[06:05] <persia> 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] <nixternal> hrmm, there were patches referenced in the series file, but they weren't in the patches directory
[06:06] <nixternal> well they were, but the names were different
[06:07] <nixternal> anywho, fixed the ftbfs, but still weird
[06:07] <nixternal> food time
[06:10] <persia> 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] <somerville32> persia, ok
[07:26] <liri> persia: should the webapps package I upload be built as source package?
[07:34] <persia> 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] <persia> 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] <persia> 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] <cyberix> Is there any package in Gutsy that uses the homepage header?
[08:13] <persia> cyberix: the Homepage: header wasn't supported in Gutsy.
[08:14] <cyberix> Oh
[08:14] <liri> persia: alright. I was just wondering how would I go about packaging a webapps (collection of scripts) package as source package
[08:15] <liri> Maybe I could contact a maintainer of a webapps package from the Ubuntu packages list
[08:15] <persia> 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] <cyberix> persia: The linda/lintian minus/hyphen warning for malbolge package looks like a false alarm to me.
[08:15] <persia> liri: Or just take a look at an example, and ask specific questions here.
[08:15] <persia> cyberix: It's not.  I checked the manpage source.
[08:16] <cyberix> persia: But it is part of a filename.
[08:17] <persia> cyberix: In which case you want to use \- as otherwise copy & paste will fail.
[08:17] <cyberix> oh
[08:17] <cyberix> man renders - as a hyphen?
[08:18] <persia> 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] <liri> 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] <liri> 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] <persia> 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] <liri> persia: I probably need someone experienced with webapps packaging to work on this with me
[08:24] <persia> 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] <Fujitsu> 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] <liri> Fujitsu: php indeed.
[08:27] <Fujitsu> 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] <persia> liri: Are you upstream?
[08:27] <liri> persia: yes. I'm the author of the software
[08:27] <Fujitsu> Because I'd like such a guideline, even if it doesn't apply here.
[08:28] <persia> Fujitsu: Yes, as long as we can show we spoke with upstream to demonstrate that.
[08:28] <persia> 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] <liri> 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] <persia> 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] <liri> Fujitsu: would you need to review the code?
[08:29] <Fujitsu> Basically, does it have a Wordpress- or phpMyAdmin-like security track record?
[08:32] <liri> Fujitsu: I'm not aware of wordpress or phpmyadmin's security track record
[08:32] <Fujitsu> Well, WordPress has had approximately 50 CVEs in the past 18 months.
[08:32] <Fujitsu> And they don't normally release patches for each issue.
[08:33] <liri> 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] <liri> 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] <Fujitsu> What's the name of the project?
[08:35] <liri> Fujitsu: daloradius
[09:24] <wraund> 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] <persia> wraund: It goes upstream.  If it can't go there, it goes in debian/
[09:38] <wraund> persia: good good :)
[10:01] <persia> 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] <minghua> Huh, sounds like so.  Is that from GPL v3? :-P
[10:03] <persia> minghua: No, from some annoying Red Hat "supplementary conditions" file.  I suspect even Fedora doesn't comply with that licensing.
[10:04] <minghua> persia: Oh, and you can distribute it on flash disks, too.  (Sorry to be pedantic, but couldn't resist. :-)
[10:04] <persia> minghua: is not "rewritable media" a superset including "flash disks"?
[10:05] <minghua> persia: Hmm.  Perhaps.  Sorry.
[10:05] <persia> minghua: No need to be sorry.  I am a confirmed pendant.  If you correct me (correctly), I am happier :)
[10:06] <Fujitsu> persia: That is a really strange license.
[10:07] <persia> 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] <Fujitsu> How very liberated.
[10:08] <persia> Well, it at least allows people to play the "Yes, I wish to exchange overlords, please" card.
[10:08] <Fujitsu> I guess.
[10:09] <Fujitsu> What's the alternative? Some Microsoft core font?
[10:09] <persia> Fujitsu: Yep.  Arial, Courier, and Times New Roman.
[10:10] <Fujitsu> Ah, old.
[10:10] <persia> old?
[10:10] <Fujitsu> Haven't they all been replaced?
[10:11] <persia> Do you mean by Vera?
[10:11] <minghua> 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] <Fujitsu> No, the new Microsoft C*
[10:12] <persia> Fujitsu: No idea.  I don't really follow Microsoft fonts.
[10:12] <minghua> Fujitsu: Liberation has the same metrics (height, width) as the MS web core fonts.  The Vera/DejaVu fonts don't.
[10:12] <minghua> Sorry, that should be for persia.
[10:13] <Fujitsu> minghua: Ahh.
[10:13] <persia> minghua: Right.  Still, it's just an overlord exchange in my book.
[10:13] <minghua> Then again, the C* fonts probably don't have the same metrics as corefonts either.
[10:13] <Fujitsu> Why do they have such a deranged license?
[10:13] <minghua> So people will still use those for web pages.
[10:14] <minghua> Redhat would be a more benevolent overlord than MS, I assume. :-)
[10:14] <Fujitsu> 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.
[10:19] <minghua> persia: Only because their original license didn't forbid redistribution.  You can no longer download them from MS website.
[10:19] <persia> 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] <persia> 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] <persia> minghua: Why not?  How is Microsoft any different than any other corporate upstream?
[10:22] <minghua> 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] <persia> minghua: Ah.  Upstream closed newer revisions.  I think we've a few other packages like that in the archive.
[10:24] <minghua> 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] <minghua> I'm sure someone in MS regretted allowing redistribution of those fonts.
[10:24] <persia> minghua: Sure.  Didn't bittorrent do that recently?  Doesn't make the old version bad.
[10:25] <minghua> persia: The old version isn't bad (I like MS corefonts), the company is (Bittorrent is becoming bad IMHO, too).
[10:26] <Fujitsu> persia: Wait, how is it even multiverse, with a nasty redistribution restriction?
[10:26] <persia> 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] <Fujitsu> minghua: Only becoming bad?
[10:27] <persia> 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] <Fujitsu> persia: The rewriteability requirement would exclude it from multiverse, wouldn't it?
[10:28] <minghua> persia: To be fair, MS corefonts' license is much more restrictive.
[10:29] <minghua> Fujitsu: I am not really following the bittorrent company story.
[10:29] <persia> 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] <Fujitsu> persia: Even so. Isn't multiverse meant to be safe to distribute regardless of medium?
[10:30] <Fujitsu> ie. I can burn a CD?
[10:31] <persia> 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] <persia> For personal use, burning a CD is perfectly fine: you just can't distribute that CD.
[10:31] <Fujitsu> Hmm.
[10:32] <Fujitsu> It still seems particularly nasty. I really don't like it.
[10:32] <Fujitsu> But I defer to elmo.
[10:32] <persia> 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] <Fujitsu> That ended up going in, didn't it? :(
[10:33] <persia> 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] <Fujitsu> Um, yeah, yay.
[10:34]  * persia doubts upstream will still be active then
[10:34] <Fujitsu> Shall I find another 50,000 or so beer-free Windows apps now?
[10:34] <Fujitsu> They should be accepted, so I'd better get busy on them.
[10:35] <persia> 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] <Fujitsu> Quite possibly. But we've just made a nasty step down a very long, steep, slippery slope.
[10:36] <persia> 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] <CheGuevara> lol
[10:36] <persia> CheGuevara: The point would be to point out the absurdity of current policy, not to actually have them included.
[10:37] <Fujitsu> Was policy ever discussed after mdz (I think?) provided his opinion?
[10:38] <persia> Fujitsu: No, and it was elmo to whom the decision was delegated (although mdz did express an opinion)
[10:38] <Fujitsu> Can't we have a MOTU meeting and block such situations again?
[10:38] <Fujitsu> Right, I forget exactly.
[10:38] <persia> Not directly.  MOTU Meeting can raise an issue to MC who can raise it to TB, but MOTU Meeting cannot override TB.
[10:40] <Fujitsu> Surely we can impose additional restrictions on multiverse licensing, or at least on new packages, without an official TB stance change?
[10:40] <Fujitsu> If not, I guess we must convince the TB.
[10:40] <CheGuevara> persia: yeah i figured :P
[10:41] <persia> 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] <hellboy195> apachelogger_: ping
[10:46] <apachelogger_> hellboy195: pong
[10:46]  * persia dislikes virtual table tennis
[10:47] <hellboy195> apachelogger_: KMuddy is a MUD client for KDE desktop environment  -->  http://en.wikipedia.org/wiki/MUD
[10:48] <apachelogger_> hellboy195: yeah, already got a description, thanks :)
[10:48] <hellboy195> apachelogger_: ok, np
[10:50] <hellboy195> apachelogger_: from your list I only know 2 by name. I only tried out Jahshaka
[10:51] <apachelogger_> jashaka is like totally over the top
[10:51]  * apachelogger_ didn't manage to use it
[10:51] <minghua> Fujitsu: Hmm, how can a slope be bother very long and very steep? :-)
[10:52] <persia> minghua: It just needs to be very large.
[10:52] <minghua> You mean very deep?
[10:53] <minghua> ... or very tall, depending on the perspective ...
[10:53] <persia> minghua: Yes.
[10:54] <hellboy195> apachelogger_: because? too complicated or b0rken?
[10:54] <apachelogger_> hellboy195: too complicate
[10:54] <persia> Does anyone have a strong opinion about $(MAKE) -j $(NCPUS) in debian/rules?
[10:55] <hellboy195> apachelogger_: mostly when something is too complicate it's fucking powerful but yeah I also worked with it a long time .. :)
[10:56] <apachelogger_> hellboy195: powerful != bad usability
[10:57] <persia> !language | hellboy195
[10:57] <ubotu> hellboy195: Please watch your language and topic to help keep this channel family friendly.
[10:57] <minghua> persia: No idea.  Although I'm aware of the existence of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209008
[10:57] <ubotu> Debian bug 209008 in debian-policy "debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS" [Wishlist,Open]
[10:57] <hellboy195> persia: sry :(
[10:58] <hellboy195> apachelogger_: but often xD for me ...
[10:58] <persia> minghua: Thanks.  I guess it's policy-in-transition, so I shan't worry about it now.
[11:17] <hellboy195> apachelogger_: work for you. If you are interested ^^ https://bugs.edge.launchpad.net/ubuntu/+bug/179528
[11:17] <ubotu> Launchpad bug 179528 in ubuntu "[needs-packaging] Kalva " [Undecided,New]
[11:26] <apachelogger_> hellboy195: looks interesting
[11:27] <hellboy195> apachelogger_: :)
[11:36] <persia> 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] <persia> superm1: Is there any documentation on the nature of the apparently massive changes to /etc/lirc/hardware.conf?
[12:22] <jscinoz> hey everyone
[12:23] <jscinoz> 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] <persia> jscinoz: Create a file called debian/compat containing the single character '5'
[12:24] <jpatrick> jscinoz: it's refering to the debian/compat file
[12:24] <jscinoz> oh thanks :)
[12:24] <jscinoz> also.
[12:25] <man-di> jscinoz: and also to the Build-Depends line, then you should B-D on debhelper (>= 5) too
[12:25] <jscinoz> yeah i have the build dependso ne
[12:25] <jscinoz> one*
[12:25] <man-di> jscinoz: and you might need to adjust your debian/*.install files
[12:26] <jscinoz> 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] <man-di> jscinoz: this is done when creating the upstream tarball (or orig tarball)
[12:26] <jscinoz> ah :P
[12:26] <jscinoz> late on new years eve here bit sleepy :P
[12:46] <cyberix> What is "a watch file to collect new upstream sources"?
[12:49] <ion_> cyberix: See uscan(1)
[12:52] <ion_> 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] <ion_> ... given hardware exists in the system (intended for scripting).
[12:55] <persia> ion_: You should really complain to upstream about the upstream version sequencing.  It's very surprising.
[12:56] <ion_> 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] <persia> ion_: No big rush.  If the next upstream is 0.0.1, I'm happy :)
[12:58] <persia> ion_: apt-mark-sync advocated.  Nice clean-up job.
[12:59] <ion_> Ok, thanks
[12:59] <ion_> I’ll use 0.0.1 as the next release, then.
[13:00] <persia> 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.
[13:13] <LucidFox> Is there a place to request Tango-style icons?
[13:16] <jscinoz> is an packagename_version.orig.tar.gz required if the package has never been packaged on debian/ubuntu before?
[13:16] <geser> LucidFox: iirc ``Cube asked in #launchpad which projects needs an (tango) icon
[13:17] <geser> jscinoz: yes, that's the upstream source from which the deb gets build in the end
[13:18] <jscinoz> 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] <geser> yes
[13:20] <jscinoz> ok
[13:20] <jscinoz> also..
[13:21] <jscinoz> 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] <man-di> jscinoz: dh_compress does this for you
[13:22] <jscinoz> i'll look up how to use it, thanks :)
[13:23] <man-di> jscinoz: if you use CDBS for packaging its already done for you automatically
[13:24] <jscinoz> im just using plain old debhelper, with scripts i've scavenged and reworked from similar packages :P
[13:25] <man-di> jscinoz: then just make sure you call dh_compress in the appropriate targets in the correct place
[13:27] <jscinoz> thanks :)
[13:27] <cyberix> So, can I find an example watch file for a Launchpad project somewhere?
[13:34] <jscinoz> yeah i need an example watch file too :P
[13:34] <persia> There are a few examples of watch files in the uscan manual page.  There might be another LP hosted project on REVU...
[13:35] <jscinoz> cheers
[13:35] <jscinoz> uscan man page had what i  needed to know
[13:37] <persia> Bah.  I saw one recently, but can't find it on REVU.  Apologies.
[13:39] <cyberix> Should my watch file just report an upgrade being available or do some hard magic?
[13:40] <slytherin> cyberix: what hard magic?
[13:40] <slytherin> cyberix: watch file should just have a url in the form of regular expression which will correspond to new release
[13:41] <jscinoz> is this a valid URL for in the watch file? ftp://ftp.snt.utwente.nl/pub/games/urbanterror/iourbanterror/source/complete/ioUrbanTerrorSource_(.*)\.zip
[13:42] <jscinoz> i know its a zip not a targz my get-orig-source handles that and makes the orig.tar.gz
[13:43] <slytherin> jscinoz: if you have get-orig-source then perhaps you don't need watch file. Please confirm it from someone else
[13:43] <jscinoz> yeah i need both according to the commenter on my revu packages
[13:44]  * persia likes both get-orig-source and a watch file
[13:44] <slytherin> jscinoz: Ok. Is the application available only from a single download location?
[13:44] <persia> jscinoz: That might complain due to the number of '/' characters.  Try sticking it in a watch file, and calling uscan --report-status from the package directory.
[13:44] <jscinoz> there are many mirrors of it i think
[13:44] <jscinoz> ill try hang on
[13:45] <jscinoz> nope doesnt complain :P
[13:45] <jscinoz> seems fine
[13:46] <persia> slytherin: Just to expand, in addition to helping collect the upstream tarball, a watch file helps populate http://qa.ubuntuwire.com/uehs/no_updated.php, which helps us try to keep Ubuntu-local software up to date.
[13:46] <slytherin> jscinoz: I guess you should then use the central url instead of a url to specific mirror
[13:46] <jscinoz> there isnt a central one i'm aware of >_<
[13:46] <slytherin> persia: thanks for info.
[13:47] <frafu> persia: thanks for the review of mousetweaks in revu. However I have a few questions. point 3: What do you mean that the .desktop files do not validate. Point 4: manpages even if they do not have a cli interface? Point 5: the text of the licenses is in the package. Has it not been uploaded?
[13:48] <jscinoz> hmm slight problem
[13:49] <jscinoz> the thing im packaging, the versioning scheme differs slightly for how i'm going to include it in ubuntu and how it is on the upstream site
[13:49] <persia> frafu: 3) I get output from desktop-file-validate in a hardy chroot.  4) Yes.  If something is confusing, the user should expect that `man program` will tell them something useful.  There are also GUI manpage browsers.  5) The build process doesn't include those files in the binary package.
[13:49] <persia> jscinoz: Use the uversionmangle option.
[13:50] <jscinoz> the version is a date, my package is using 20071220, but the upstream site uses 2007_12_20 resulting in it thinking local is newer than mirror due to lack of underscores, any way around this?
[13:50] <jscinoz> thanks
[13:51] <jscinoz> ugh regexps confuse me >_<
[13:55] <jscinoz> yay for trial and error until it worked
[13:55] <jscinoz> used opts=uversionmangle=s/_//;s/_//
[13:55] <persia> jscinoz: Try s/_//g
[13:56] <jscinoz> alright one sec
[13:56] <jscinoz> ugh
[13:56] <jscinoz> one other problem
[13:56] <cyberix> Can I use both the mangled and unmangled forms after mangling?
[13:57] <jscinoz> this game im packaging has three packages, client, server and data files
[13:57] <jscinoz> but they use completely different versioning schemes, the data uses 4.* while the client and server use YYYY_MM_DD
[13:57] <persia> cyberix: Could you expand your question a little?
[13:58] <superm1> persia, there will be on the wiki after i write it :)
[13:58] <persia> jscinoz: Best to track upstream: the version skew should mostly be hidden by package dependencies anyway.
[13:58] <persia> superm1: Excellent.  I'll wait for that before pressing one of Y/I/N/O/D/Z then :)
[13:58] <jscinoz> is it acceptable to have: urbanterror (20071220) urbanterror-server (20071220) and urbanterror-data (4.1)?
[13:59] <superm1> persia, the way that I wrote it, you can press Y or N and it will rebuild your hardware.conf safely
[13:59] <cyberix> https://launchpad.net/msk/0.1/0.1.1/+download/malbolge-0.1.1.tar.gz
[13:59] <persia> jscinoz: Very much so.
[13:59] <cyberix> https://launchpad.net/msk/0.1/([\d\.]*)/+download/malbolge-([\d\.]*).tar.gz
[13:59] <cyberix> I suppose I still have to do something for the "0.1"
[13:59] <persia> superm1: That's very confusing.  If it's going to rebuild it, I'm not convinced it's really a conffile.
[14:00] <jscinoz> ok thanks :)
[14:00] <superm1> persia, well due to some changes i made during gutsy, all of the parameters come from a hardware database
[14:00] <persia> cyberix: Is there an LP page that lists all downloads for a project, or is it only versioned?
[14:00] <superm1> so provided your remote is in that database, it can rebuild the changes
[14:00] <jscinoz> next time i dput to revu though, isnt it going to upload as a new package due to the changed versioning scheme on my packages?
[14:00] <superm1> if it isnt, then you can put custom items instead
[14:01] <cyberix> I suppose this is it https://launchpad.net/msk/+download
[14:01] <persia> superm1: Hmm.  That sounds better.  If it's possible to reliably detect user hardware, and do the right thing, that sounds better.  On the other hand, I have 2 IR devices.  One always connected, and the other only sporadically (and the second is the one for which I prefer the remote).  Will it do the right thing for me?
[14:01] <cyberix> So, yes
[14:02] <superm1> persia, well do the modules for your two ir devices modprobe on their own normally?
[14:02] <superm1> due to udev
[14:02] <persia> cyberix: In that case, consider using the screen-scraper mode, where the first part is the page to scrape, and the second is the URL checker.
[14:02] <persia> superm1: Likely not in a useful way, but yes (one is usbserial and is also a LCD device)
[14:03] <frafu> persia: I have another question about the changelog: after fixing the problems you indicated in the package, should I not update the changelog with information about it; and also increment the version of the package? Or are you not talking about debian/changelog?
[14:03] <cyberix> That is the version 2 stuff that is deliberately left undocumented in the man pagE?
[14:03] <superm1> persia, later on, i was planning another change that was going to blacklist all but the modules you selected in the hardware.conf.  it should properly handle at that point
[14:03] <jscinoz> hmm
[14:04] <persia> frafu: I probably was talking about debian/changelog.  No need to update the version, as it didn't get uploaded to the repositories.  debian/changelog should primarily contain information interesting to developers & end-users, not reviewers, so no need to add entries there unless they would be appropriate to that audience.
[14:04] <superm1> persia, because there has been many people with that issue, where they have say a VFD and additionally a mceusb2
[14:05] <persia> superm1: Then I'll go with 'Y' for now, and expect it will get sorted later (as I don't feel like hunting my remote just now).  I'm still not sure it's really a conffile.  Thanks.
[14:05] <superm1> persia, if you have other ideas for how to handle it, feel free to throw them out this way :)
[14:05] <persia> superm1: Should they all get blacklisted?  What about products like http://www.soundgraph.com/Eng_/Products/imon26.aspx?topMenu=2&subMenu=1&leftMenu=26 ?
[14:06] <frafu> persia: thanks for your help; happy new year;  i have to quit now.
[14:06] <superm1> persia, well if you set your remote to be the imon pad, and say your transmitter to be your usb device, those two won't be blacklisted
[14:06] <persia> superm1: If you are detecting the hardware, and have a script that redetects (perhaps wrapped under dpkg-reconfigure), then I'd just have it be a configuration file in /etc, rather than a conffile.  Policy says you're not supposed to automangle conffiles.
[14:07] <persia> superm1: Further, I think autodetection is a better solution.  An ideal system doesn't need conffiles, as the user doesn't need to override anything: it just works.
[14:07] <superm1> persia, well lets put it this way.  the way it works right now, the conffile is only mangled under two conditions:
[14:08] <superm1> persia, 1) if you change your remote/transmitter when debconf asks you for your remote/transmitter
[14:08] <superm1> persia, 2) if the configuration is currently broken
[14:09] <superm1> autodetection is a better solution, but only works for devices that explicitly identify themselves (such as usb devies)
[14:09] <persia> superm1: Hmm...  policy says it's supposed to stay broken, but I guess that makes some sense.
[14:09] <superm1> i2c, serial, parallel don't handle
[14:09] <jscinoz> i really hate my isp at the moment.
[14:10] <persia> Ah, so that's why my MX2 doesn't work easily: it's serial (via USB serial), so there's no way to tell there is a IR receiver there.
[14:10] <superm1> persia, exactly
[14:10] <superm1> so at some point you do have to be asked about it
[14:11] <superm1> persia, do we have your MX2 in the lirc.hwdb already, or no?
[14:11] <persia> superm1: lirc.hwdb?
[14:12] <superm1> persia, the database that populates those debconf questions off the bat
[14:12] <superm1> /usr/share/doc/lirc/lirc.hwdb
[14:12] <superm1> additionally as of this package: /usr/share/doc/lirc/transmitter.hwdb
[14:12] <persia> superm1: No.  None of the Matrix Orbital devices appear there.
[14:13] <superm1> persia, is there a standard lircd.conf used for it?
[14:14] <persia> superm1: I don't think so.  It's just an IR receiver.  You'd have to set the programming to match some remote you pointed at it (it also works for ircomm, etc. if you like).
[14:14] <jscinoz> hmm so for the get-orig-source, using in conjunction with the watch file, the best way to do it would be... uscan --force-download --no-symlink || mkdir orig || unzip ../ioUrbanTerrorSource_2007_12_20  -d ./orig|| tar -cz urbanterror-20071220.orig.tar.gz ./orig?
[14:14] <jscinoz> something like that?
[14:15] <superm1> persia, okay but normally it uses lirc_serial for the driver?
[14:15] <persia> superm1: Yes.
[14:15] <jscinoz> im sure i could streamline that with stdin and stdout somehow
[14:15] <superm1> persia, if you can file a bug, and explain these things, next go around i'll add it to the hwdb
[14:15] <superm1> and mark it as user generated lircd.conf
[14:15] <superm1> but that way it will be able to automatically setup the driver for lirc_serial
[14:16] <persia> jscinoz: Looks reasonable.  There are some examples at https://wiki.ubuntu.com/PackagingGuide/Basic#head-4bb01b3c07548aaf98e85ac7eb7983e632f8eb38
[14:16] <jscinoz> thanks
[14:17] <persia> superm1: I usually use the i.Mon knob for lircd anyway.  I'll add setting up the MX2 with a remote to my todo list, but it won't be a terribly high priority (personally, I doubt many people primarily use the MX2 for lirc: ircomm is more common).
[14:18] <superm1> persia, ah i see.  well additionally, does your imon have a pad?
[14:18] <superm1> i'd be interested to see if that pad2keys patch that was applied a few revisions ago is working properly
[14:18] <persia> superm1: http://www.soundgraph.com/Eng_/Products/imon23.aspx?topMenu=2&subMenu=1&leftMenu=23 is the one I have.  Does it have a pad?
[14:18] <superm1> someone requested it a few months back, but it was put into hardy, so they weren't going to be able to test it until beta/rc time
[14:19] <superm1> persia, yeah that big thing with the arrows is considered the pad
[14:19] <superm1> it can be read as an analog or digital input per my understanding
[14:19] <persia> OK.  it's fairly late here, but I'll dig out the remote in the next couple days, and give it a test.
[14:22] <superm1> persia, great thanks
[14:28] <jscinoz> gah
[14:28] <jscinoz> how do i test out my get-orig-source without building the whole package.
[14:28] <Vorian> persia: where should we submit package updates again?  :)
[14:29] <persia> jscinoz: Just run debian/rules get-orig-source in the package directory, and make sure the resulting orig.tar.gz matches what you expect.
[14:29] <persia> Vorian: Submit an interdiff to the sponsors for review.  See https://wiki.ubuntu.com/MOTU/Contributing
[14:29] <jscinoz> alrighty thanks
[14:30] <roderik> I'm trying to package a program to put in a ppa that depends on libdvdread3, but my pbuilder keeps telling that libdvdread, libdvdread3, libdevread-dev and libdvdread3-dev are virtual packages. Does anyone have an idea what package to use?
[14:32] <persia> roderik: apt-cache tells me the libdvdread source package builds libdvdread3 and libdvdread-dev.  Does your pbuilder know about universe?
[14:33] <roderik> probably not :) i just did pbuilder create --distribution=gutsy
[14:35] <jscinoz> persia is there a way to get uscan to output both the mangled and unmangled versions?
[14:36] <persia> jscinoz: No idea.  Maybe someone else knows (a good reason to ask questions to the channel generally)
[14:36] <jscinoz> alrighty
[14:36] <jscinoz> is there a way to get uscan to output both the mangled and unmangled versions?
[14:36] <jscinoz> :P
[14:43] <jscinoz> what would be a regexp to insert an underscore after 4 characters, then two, then two again, eg changing 20071220 to 2007_12_20?
[14:43] <cyberix> persia: I suppose I've fixed all your complaints now. http://revu.tauware.de/details.py?package=malbolge
[14:46] <persia> jscinoz: A regex can't do that.  The sed fragment s/\(\d\d\d\d\)\(\d\d\)\(\d\d\)/\1_\2_\3/ ought do it, but it's rather ugly.  There's probably a better way.
[14:46] <jscinoz> hmm
[14:46] <jscinoz> ok thanks :P
[14:47] <persia> cyberix: I firmly believe you get the best quality package with multiple reviewers.  Best to ask for someone else to look at it first (although I will if nobody else does in a while).
[14:49] <jscinoz> argh
[14:51] <cyberix> I'm looking after first advocate for my package malbolge. I've posted the package to REVU and fixed all problems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
[14:52] <jscinoz> hey guys
[14:52] <jscinoz> im trying to get my get-orig-source working in conjunction with my watch file
[14:53] <jscinoz> heres a pastebin of the get-orig-source rule and the problems happening http://pastebin.ubuntu-nl.org/50261/
[14:53] <jscinoz> any ideas?
[14:55] <LucidFox> jscinoz> don't determine version using uscan
[14:55] <LucidFox> use dpkg-parsechangelog
[14:57] <jscinoz> i need it to fetch the zip too though thats why i used uscan
[14:57] <cyberix> Unless someone has time to look at my package right now, I think I'll go out and find some food.
[14:58] <cyberix> Then I'll hopefully be back in time to fix one or two remaining bugs, and will get the package into queu before next year.
[14:58] <cyberix> ;-)
[14:59] <jscinoz> hmm
[15:00] <persia> Happy New Year
[15:00] <jscinoz> happy new year :P
[15:01] <persia> jscinoz: Looking at that get-orig-source, I suspect you need to add a tar somewhere between unzipping and gzipping.  You might also look at the output of uscan --dehs to see if the upstream version is available there.  I'm also not convinced "$$(version |sed s/\(\d\d\d\d\)\(\d\d\)\(\d\d\)/\1_\2_\3/)" is the right syntax.
[15:01] <cyberix> Happy New Year, to you too.
[15:01] <cyberix> persia: and thanks
[15:03] <txwikinger> persia: Already?
[15:03] <txwikinger> Happy New Year then
[15:03] <persia> txwikinger: Apparently :)
[15:04]  * txwikinger stil hangs on to 2007
[15:05] <jscinoz> i got some things to work right but i cant get it to add in the 3 undersccores >_<
[15:06] <jscinoz> is tar -cz the same as tar then gzip?
[15:06] <persia> jscinoz: Yes, but it may not be --best
[15:07] <jscinoz> hmm
[15:10] <persia>  /msg ubotu bug #162966
[15:10] <ubotu> Launchpad bug 162966 in ubuntu "libserial needs packaging" [Undecided,In progress] https://launchpad.net/bugs/162966
[15:18] <jscinoz> ugh
[15:36] <jscinoz> can tar even make an archive from stdin?
[15:41] <jscinoz> ugh tar is so stupid.
[15:50] <jscinoz> im off to bed i cant figure this out >_<
[15:50] <jscinoz> night all
[16:01] <slytherin> is it necessary to change 'Standards-Version' to 3.7.3 while fixing a FTBFS?
[16:01] <geser> no
[16:02] <slytherin> What is new in this standard version by the way?
[16:02] <jpatrick> 3.7.3
[16:02] <geser> slytherin: we try to keep the delta to Debian small
[16:02] <slytherin> geser: sure. :-)
[16:02] <geser> slytherin: see http://lists.debian.org/debian-devel-announce/2007/12/msg00001.html
[16:06] <chazco> Hi... i'm creating a .deb for a propriety application... Is there an "accepted" way of setting up mime.types (it uses the file extensions .tmd and .pmd) I should use?
[16:18] <slytherin> what is the way to non-interactively accept Sun's license in local pbuilder chroot?
[16:22] <geser> slytherin: the buildds do it through preseeding the debconf question, so it should also work in pbuilder but I haven't looked yet how to do it
[16:24] <slytherin> geser: I have logged in to pbuilder and now trying to install Sun JRe manually, but I get error that license could not be presented. It asks me to do 'dpkg-reconfigure debconf' but that too doesn't help
[16:30] <geser> is perhaps the debconf frontend set through a environment variable?
[16:32] <geser> slytherin: try unsetting DEBIAN_FRONTEND (which is set to noninteractive)
[16:34] <slytherin> geser: Worked, thanks
[16:34] <man-di> slytherin: last time I did that I did "pbuilder --save-after-login login" and did a "chroot dir" in another terminal to the pbuilder dir
[16:34] <geser> Hi bddebian
[16:35] <slytherin> man-di: I am doing the same
[16:35] <slytherin> man-di: except that chroot part
[16:35] <bddebian> Heya geser
[16:39] <slytherin> One more FTBFS fixed. Will submit debdiff tomorrow. Happy New Year to all in advance. Good night.
[16:39] <SnackPack> oi.
[16:41] <jpatrick> SnackPack: hello, happy new year
[16:42] <SnackPack> danke, you too
[16:43] <SnackPack> so I'm reading up on how to become a motu
[16:43] <jpatrick> bitte
[16:43] <SnackPack> lotsa links to read
[17:10] <chazco> Hi... i'm creating a .deb for a propriety application... Is there an "accepted" way of setting up mime.types/file associations (it uses the file extensions .tmd and .pmd) I should use? I'm aiming for as great a range of compatibility as possible.
[17:53] <SnackPack> hmmm
[17:54] <SnackPack> it's hard to find bugs that don't already have diffs uploaded
[18:01] <AnAnt> Hello, I am making a package, the issue is that the orig is in SVN, how should I handle that case ?
[18:02] <geser> AnAnt: svn export to get a tarball without the .svn dirs
[18:04] <AnAnt> that's not what I meant
[18:04] <AnAnt> geser: I mean, what URL should I mention in copyright
[18:04] <SnackPack> is it recommended to just apply for mentorship?
[18:04] <AnAnt> geser: and is there a field to add in control file ?
[18:05] <AnAnt> geser: the reason I ask, is because once I done apt-get source <some package>, and it got pulled from BZR or SVN
[18:05] <geser> AnAnt: the svn URL
[18:06] <geser> AnAnt: the fields in debian/control specify in which VCS (if any) the debian packaging is done
[18:07] <AnAnt> geser: so if the debian package itself is in SVN, I should mention that in debian/control ?
[18:08] <AnAnt> geser: I mean source package
[18:08] <geser> only if you (as the maintainer) use a SVN for the debian/* files
[18:09] <AnAnt> geser: ok, what's the field name ?
[18:13] <geser> Vcs-Svn for your svn repository and Vcs-Browser if it's also viewable in a browser
[18:14] <AnAnt> geser: so, if the svn URL is http:// I should use both Vcs-Svn & Vcs-Browser ?
[18:14] <geser> yes
[18:15] <geser> do you really do the whole packaging in a svn repository already?
[18:15] <SnackPack> I guess I'll wait for the next motu meeting to look at starting to become a motu
[18:16] <AnAnt> geser: yes, actually the save svn repository in which the package resides
[18:16] <AnAnt> geser: yes, actually the same svn repository in which the package resides
[18:17] <txwikinger> How can I figure out why a package was removed and/or superseeded and if superseeded with which package?
[18:18] <geser> txwikinger: check if there is a bug or in the removal log
[18:18] <geser> SnackPack: have you read the MOTU pages in the wiki already?
[18:18] <txwikinger> geser no bug ... and in the overview it only says superseeded
[18:19] <SnackPack> geser: yeah I've been reading
[18:19] <SnackPack> looks like most bugs have a diff already posted
[18:19] <geser> txwikinger: which package?
[18:19] <txwikinger> geser: https://edge.launchpad.net/ubuntu/+source/libooc-x11/
[18:19] <geser> SnackPack: look at https://wiki.ubuntu.com/MOTU/TODO for tasks
[18:21] <SnackPack> geser: how si that different from https://edge.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs ?
[18:21] <geser> txwikinger: http://people.ubuntu.com/~ubuntu-archive/removals.txt says "(From Debian) RoQA; no users; RC-buggy; unmaintained"
[18:21] <txwikinger> well then I can just close the open bugs I guess
[18:22] <geser> SnackPack: that shows the bugs which are already done by contributors (by e.g. providing a debdiff) and only need a review and upload from a MOTU
[18:24] <geser> SnackPack: the workflow is: a contributor finds a problem or bug he can fix, prepares a debdiff, files a bug with the debdiff (if none exists), subscribe ubuntu-univers-sponsors for sponsoring the upload
[18:25] <SnackPack> geser: ok, so I can choose one or more from this TODO list and follow the patching guidelines?
[18:25] <SnackPack> k
[18:26] <geser> yes
[18:26] <SnackPack> woot
[18:28] <SnackPack> time to get a hardy installation going.  :P
[18:31] <geser> you can of course also fix other bugs which you find nasty enough to fix :)
[18:32] <SnackPack> I was wondering about that...  I'm free to hit bugs in main/multiverse/universe in order to become motu?
[18:33] <geser> yes, but for main subscribe ubuntu-main-sponsors instead of ubuntu-universe-sponsors
[18:34] <SnackPack> gotcha
[18:34] <geser> you can also choose the help specific teams, like the kubuntu team, the desktop team, etc.
[18:35] <SnackPack> I'm more of a server guy, but once I get into it, I'm sure I will
[18:35] <SnackPack> thanks
[18:35] <geser> there is also a server team
[18:36] <geser> so if you like helping to improve the server edition of ubuntu, there you go
[18:42] <AnAnt_> anyone knows how the login sound is set ?
[18:42] <AnAnt_> is it a gconf key or some conf file ?
[18:52]  * jonnymind is away: dinner
[19:01] <Kmos> http://pastebin.com/d49a8037e - Error in perl package when doing dpkg-buildpackage -S -sa -rfakeroot
[19:02] <Kmos> there is a option in dpkg-buildpackage to bypass this?
[19:19] <geser> Kmos: try installing libmodule-build-perl
[19:20] <Kmos> geser: it works. thanks
[19:20] <geser> Kmos: for some package you need some of the build-depends installed to do a dpkg-buildpackage -S
[19:21] <Kmos> geser: yeah.. i think it just bypass it =) but i'm wrong.. hehe, learned one more thing
[19:21] <Kmos> thanks
[19:21] <Kmos> i'm trying to fix a FTBFS
[19:22] <Kmos> it builds fine in pbuilder, but not at buildd machines
[19:30] <Kmos> geser: can you look at this one - bug 164166
[19:30] <ubotu> Launchpad bug 164166 in ebug-http "FTBFS: tries to download from CPAN" [Critical,Confirmed] https://launchpad.net/bugs/164166
[19:33] <chazco> Hi... i'm creating a .deb for a propriety application... Is there an "accepted" way of setting up mime.types/file associations (it uses the file extensions .tmd and .pmd) I should use? I'm aiming for as great a range of compatibility as possible.
[20:22] <ion_> Could i get a second person to advocate http://revu.tauware.de/details.py?package=hardware-connected (a program that indicates whether given hardware exists in the system; useful for scripting) and http://revu.tauware.de/details.py?package=apt-mark-sync (a program that synchronizes the “automatically installed” status of packages between different package managers)? Thanks.
[21:17] <NickPresta> I installed xcdroast (sudo apt-get install xcdroast). It wanted to install `cdda2wav` and `xcdroast`. Okay, did that. I start up xcdroast and I get an error about missing `icedax` and some missing libraries. I had to install icedax to fix it. Shouldn't icedax be a dependency of xcdroast?
[21:17] <NickPresta> This is on Kubuntu Gutsy as well.
[21:22] <Kmos> NickPresta: maybe it should be
[21:22] <Kmos> https://bugs.launchpad.net/ubuntu/+source/xcdroast/+filebug
[21:22] <Kmos> file a bug here about that
[21:23] <Kmos> and mention you're using Kubuntu Gutsy
[21:23] <Kmos> !info libtest-harness-perl hardy
[21:23] <ubotu> libtest-harness-perl: Run Perl standard test scripts with statistics. In component universe, is optional. Version 3.03-1 (hardy), package size 156 kB, installed size 512 kB
[21:24] <NickPresta> Kmos, okay, thanks. I was in the process of filing a bug but I wanted to make sure I wasn't missing something obvious.
[21:33] <Kmos> kmos@bash:~$ apt-cache show xcdroast |grep icedax
[21:33] <Kmos> it doesn't have any icedax package
[21:37] <NickPresta> Kmos, well, I just tested it by uninstalling icedax and xcdroast failed to start. Installing icedax fixed the problem.
[21:37]  * NickPresta shrugs
[21:42] <Kmos> NickPresta: so that's the problem =) report it.. and thanks for help
[21:42] <Kmos> maybe you should report it also in debian
[21:43] <Kmos> http://packages.qa.debian.org/x/xcdroast.html
[21:44] <SnackPack> Kmos: report it in debian if the package doesn't -ubuntu?
[21:44] <SnackPack> er, isn't
[21:44] <Kmos> bug 179614
[21:44] <ubotu> Launchpad bug 179614 in xcdroast "xcdroast requires icedax but not installed" [Undecided,New] https://launchpad.net/bugs/179614
[21:44] <Kmos> :)
[21:44] <imbrandon> report it in debian either way, they will benifet from the fix
[21:44] <imbrandon> SnackPack: ^
[21:44] <NickPresta> Kmos, heh okay. Reported here (https://bugs.launchpad.net/ubuntu/+source/xcdroast/+bug/179614). I shall report it to Debian too.
[21:45] <SnackPack> gotcha
[21:45] <SnackPack> question...  I'm looking at #179612
[21:45] <Kmos> I think icedax should depends on cdda2wav
[21:46] <Kmos> and not xcdroast
[21:46] <SnackPack> since I use mythbuntu at home, #179612 is of interest to me...  but I have not seen the behavior he describes
[21:46] <Kmos> SnackPack: try to uninstall cdda2wav and icedax and run xcdroast to see if it runs
[21:46] <Kmos> without it
[21:47] <SnackPack> Kmos: I'm not on that bug.  :P
[21:47] <SnackPack> was just a general question
[21:47] <Kmos> i'm talking about the "xcdroast requires icedax but not installed"
[21:48] <Kmos> I need to go.. Good Year for everyone!
[21:48] <NickPresta> Have a good night, Kmos
[21:48] <SnackPack> yeah, I'm not on that
[21:48] <Kmos> here is still 21:48 =)
[21:48] <Kmos> thanks
[21:48] <SnackPack> hehe
[21:48] <Kmos> SnackPack: that's for NickPresta
[21:48] <Kmos> NickPresta: try to uninstall cdda2wav and icedax and run xcdroast to see if it runs
[21:48] <Kmos> :)
[21:48] <Kmos> sorry
[21:48] <SnackPack> np
[21:49] <SnackPack> trying to get a hardy system going right now
[21:49] <Kmos> cya
[22:01] <NickPresta> Is it possible to use reportbug to send a bug report to Debian? I am using reportbug but it wants to send a bug report to Ubuntu as well. I've already filed a bug with LP though.
[22:02] <imbrandon> NickPresta: not from ubuntu, you have to be on a debian system to use report bug
[22:02] <imbrandon> to report it to debian bts
[22:03] <imbrandon> although you can use "bts" to submit a bug iirc from ubuntu , or just plain email
[22:03] <NickPresta> imbrandon, ah okay. The people at #Debian told me to use reportbug despite being on Kubuntu
[22:03] <imbrandon> NickPresta: they were mistaken
[22:06] <imbrandon> :)
[22:50] <persia> nixternal: erable: Is qdevelop really in the repos?  I can't find it (although https://launchpad.net/ubuntu/+source/qdevelop/ oddly works)
[22:53] <nixternal> I have uploaded it before
[22:53] <nixternal> I think
[22:53] <persia> nixternal: I didn't see it in the queues either (checked NEW, ACCEPTED, REJECTED, and DONE).  Hmmm...
[22:55] <persia> nixternal: Not in hardy-changes either, nor p.qa.d.o, so it wouldn't be a hidden sync.  Odd that it has an LP page though: did it maybe go to a PPA or something?
[22:55] <nixternal> Package qdevelop is not available, but is referred to by another package.
[22:55] <nixternal> This may mean that the package is missing, has been obsoleted, or
[22:55] <nixternal> is only available from another source
[22:55] <nixternal> hrmm
[22:55] <nixternal> it shows up in apt-cache as well
[22:56] <persia> nixternal: Not in my apt-cache.  Do you have extra sources?
[22:56]  * nixternal looks
[22:56] <nixternal> no I don't
[22:57] <persia> nixternal: Curiouser and curiouser...
[22:57]  * Fujitsu points at apt-cache policy.
[22:57] <nixternal> no doubt
[22:58] <Fujitsu> nixternal: Do you have it installed?
[22:58] <nixternal> doesn't look like it
[23:00] <Gunirus> Happy New Year
[23:00] <nixternal> Happy Gnu Year to you as well :)
[23:00]  * persia cheers pidgin
[23:01] <Gunirus> thx :p
[23:31]  * persia grumbles that 2048 characters is insufficient for some REVU results
[23:31] <mekius> hey, gnome-hearts package seems to be missing the cards in gutsy
[23:32] <persia> mekius: Is there a bug?
[23:32] <mekius> well of course :), it crashes without the cards
[23:33] <persia> mekius: I mean, has a bug been filed?  The cause is likely due to differences between Ubuntu and Debian gnome-games, but without a filed bug, it's not likely to be fixed soon (especially as gnome-hearts works for me, and at least two other people).
[23:33] <mekius> I just installed it and not working, made sure gnome-cards-data was installed, neither package has the necessary files
[23:34] <persia> mekius: Right.  You probably want to file a bug.  Also #ubuntu-bugs is a better forum to discuss bugs.
[23:34] <mekius> i can look for a bug
[23:34] <mekius> k
[23:36] <mekius> well I'll deal with this later, don't have time right now
[23:59]  * XSource_ Accept/Balls To The Wall - global german radio network - Various (x«amarok)