[00:06] <binarymutant> if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
[00:31] <laprice> is there a way to override dch -i putting 'jaunty' as the release?
[00:31] <coppro> with a text editor?
[00:33] <Laney> man dch, there is a parameter for that
[00:33] <pochu> dch -D foo
[00:33] <laprice> OK, found it. thanks
[00:59] <laprice> So I have built the package, am I right in thinking that debsign goes out to a key repository because it gives me an error, and it never asks for my passphrase.
[01:01] <laprice> building it unsigned is fine for this pass, but I probably do need get the keys figured out so that I can build official packages for replicator :-)
[01:01] <james_w> it uses your local keyring
[01:02] <james_w> but it looks for a key with a UID which byte-for-byte matches what is in debian/changelog
[01:02] <james_w> you can tell it what key to use with the -k option, or make debian/changelog match a UID on the desired key
[01:05] <sooth> Are PPA packages signed with maintainer's key?
[01:06] <raof> No.
[01:20] <ScottK> Source is
[01:20] <nhandler> Ok, I am almost positive that there is something wrong with pbuilder (or the related packages) for intrepid
[01:22] <ScottK> nhandler: Then how come you're the only one with a problem?
[01:22] <ScottK> That I know of anyway....
[01:22] <nhandler> ScottK: I have no clue. But I just did a fresh install (again) with the same problem.
[01:22] <nhandler> Since I'm using the same pbuilderrc as some other people, I don't think that is the issue
[01:22] <ScottK> nhandler: Want my pbuilder wrapper script?
[01:23] <nhandler> ScottK: Let me see it. vorian already had me try one which failed
[01:23] <ScottK> After I saw you discuss this last, I made a new one with it.
[01:23] <ScottK> OK.
[01:24] <ScottK> nhandler: http://pastebin.com/f659051c5
[01:27]  * ScottK considers the very idea of php-gnupg as questionable.
[01:41] <nhandler> ScottK: The wrapper script failed too.
[01:42] <vorian> nhandler: which debootstrap are you using?
[01:42] <vorian> backport?
[01:42] <nhandler> vorian: Yeah, 1.0.10ubuntu1~intrepid1
[01:43] <vorian> hmmm
[01:43] <nhandler> I even tried the jaunty debootstrap a few days ago, but it didn't help
[01:46] <ScottK> nhandler: What error?  I've forgotten
[01:51] <tritium> wgrant: when you have a minute, please ping me re: MOTU Science team issues
[02:02] <nhandler> ScottK: Err http://archive.ubuntu.com jaunty/main libcwidget3 0.5.12-3ubuntu1 Could not resolve 'archive.ubuntu.com'
[02:02] <nhandler> (That comes up for all of the packages)
[02:04] <Hobbsee> ie hte /etc/resolv.conf in the pbuilder is wrong.  strange...
[02:39] <nhandler> Hobbsee: Is there any way to fix that? Since the chroot isn't created, I can't do a pbuilder login
[02:48] <StevenK> nhandler: You can run debootstrap by hand, and try and correct any problems it comes up with
[02:50] <nhandler> I'll give that a try StevenK
[02:52] <Hobbsee> nhandler: use pbuilder login --save-after-login?
[02:56] <mrooney> vorian: would you mind checking out my changes to http://revu.ubuntuwire.com/details.py?package=wxbanker when you have a minute?
[02:56] <ScottK> I dont think you can login until after its created.
[02:56] <Hobbsee> oh, the problem is creating it in the first place.  got it
[02:56] <mrooney> vorian: I found a package using the same icon set as I am, so that was super helpful :)
[02:58] <Hobbsee> nhandler: you're not running a local nameserver or anything, are you?
[03:24] <ScottK-desktop> nhandler: You don't happen to have the resolveconf package installed do you?
[03:24] <ScottK-desktop> Err resolvconf
[03:26] <Hobbsee> that too
[04:55] <jsmidt> I am going to ask what may sound as a dumb question but please be patient.
[04:56] <jsmidt> Both the PackageUpdate and MOTU/TODO encourage us to be merging and syncing.
[04:57] <jsmidt> The sync page asks that we only request syncs that improve Ubuntu.
[04:57] <jsmidt> But the reaity is there are several packages that would improve Ubuntu through bug fixes and new features.  It really is subjective.
[04:57] <jsmidt> What is the rule of thumb when making these requests?
[04:57] <ScottK> This is correct.
[04:57] <ScottK> It's a question of risk and benifit.
[04:58] <ScottK> Assessment of these is subjective and requires experience.
[04:58] <jsmidt> Should I just go to town and request anything I think would benifit Ubuntu?
[04:58] <ScottK> I'd suggest start small.
[04:58] <jsmidt> I'm only asking because it is a main todo and I want to be helpful.
[04:58] <ScottK> Pick a few and suggest them.  See how it goes.
[04:59] <ScottK> You're main job when you're new is learning.
[04:59] <ScottK> So don't go overboard with requests.
[04:59] <jsmidt> Okay, since I can't do the actual uploading and was scolded for doing debdiffs for syncs, should I at least upload a build log?
[04:59] <ScottK> Focus on picking what you think are important things and see what's good.
[05:00] <ScottK> You should definitely test build.  No need to actually upload the log.  The sponsor will test build it anyway.
[05:02] <jsmidt> ScottK, thanks.  "You're main job when you're new is learning."  I really am trying.
[05:02] <ScottK> Good.  Just keep at it.
[05:09] <binarymutant> if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
[05:15] <raof> Ok, time to fix us some dbus permissions on packagekit.
[05:17] <jsmidt> Is there a way to get a feed for packages with a particular tag, like patch?
[05:28] <raof> jsmidt: I don't think so, but haven't dug into that particularly.
[05:31] <milli> ScottK: has a freeze date been set for Jaunty yet?
[05:32]  * milli would like to get Rails 2.2.2 in soon, with fixed depends
[05:33] <raof> milli: It'll be on wiki.ubuntu.com.
[05:33] <raof> https://wiki.ubuntu.com/JauntyReleaseSchedule
[05:35] <milli> raof: ty...  guess I need to hassle the Debian maintainer first...  there are security fixes beyond 2.1.0 that's in sid too...
[06:27] <StevenK> bigon: Can you please include more information in your sync requests? Having to dig up two changelogs and then compare changes is very tiresome.
[06:56] <stochastic> I'm trying to package my second package, but it relies on qmake so I'm not sure how to format the changes to the debian/rules file.  Are there any good qt packaging guides around?
[06:56] <Amaranth> stochastic: your best bet is to find another package that uses qmake
[07:27] <dholbach> good morning
[07:31] <iulian> G'morning dholbach.
[07:31] <dholbach> hiya iulian
[08:33] <dholbach> soren: I got ~ubuntu-motu merged into ~motu. It's done now.
[08:43] <slomo_> raof: could you merge/sync banshee 1.4.2, ipod-sharp 0.8.2 and podsleuth 0.6.4 from experimental? if you need to do any changes except changing libgnome2.0-cil to libgnome2.24-cil please tell me ;)
[08:46] <raof> slomo_: If you update f-spot, sure!
[09:14] <stochastic> I uploaded a fix to bug #211798 a few weeks ago but there's been no sign of activity since.  Do I need to mark the bug as fixed before the debdiff is accepted into the repos?
[09:16] <dholbach> thekorn, jpds: do you have any idea why the new grab-attachments (using lplib) do unzip zipped attachments (.diff.gz)?
[09:17] <DktrKranz> stochastic: no, unless your bug is already fixed in jaunty.
[09:17] <stochastic> DktrKranz, is there anything I can do other than wait now?
[09:19] <DktrKranz> stochastic: waiting is the key here. I could have a look this evening, since I've no UI here.
[09:19] <DktrKranz> *GUI
[09:20] <stochastic> Okay, I'm just making sure its not going under the radar for jaunty
[09:20] <DktrKranz> stochastic: if you're around this evening (europe timezone), please remind me :)
[09:23] <thekorn> dholbach, hmm, really? let me check, I'm sure I did not change anything related to handling of zipped files in this tool
[09:26] <thekorn> dholbach, it looks like it's a 'feature' of launchpadlib, zipped content is automatically unzipped
[09:30] <dholbach> narf :)
[09:33] <thekorn> go, report a bug!
[09:37] <RAOF> I always forget; if I upload a Banshee merge which build-depends on some new syncs, that's fine - it'll happily sit in dep-wait until the version is satisfied, yes?
[09:38] <persia> RAOF, As long as you're using unsatisfied versioned build-depends, it ought.  Worst case, it's just a rebuild for the build failure.
[09:38] <DktrKranz> RAOF: yes, unless there are broken inner dependencies, in that case a give-back is enough to have things done.
[09:38] <persia> (and we can do give-backs with the UI now :) )
[09:38] <RAOF> Oh, we can, can't we.  Yay!
[09:38]  * DktrKranz hugs persia
[09:39] <DktrKranz> "Yes, we can" (cit.)
[09:46] <DktrKranz> RAOF: if you need a hand to clear those, count on me. I want to be able to upgrade banshee again ;)
[10:10] <RAOF> DktrKranz: You're welcome to help.  The relevant bug is bug #314516
[10:17] <RAOF> The world has no right to be 30°C at 9pm.
[10:18] <dholbach> RAOF: 1°C here :)
[10:18] <jpds> It's 3*C here.
[10:18] <ogra> yeah
[10:18] <RAOF> dholbach: Trade you? :)
[10:18]  * ogra would love to be where RAOF is
[10:18] <RAOF> Sydney.  Sweet, sweaty, humid Sydney.
[10:23] <DktrKranz> RAOF: I know, I filed it ;)
[10:27] <DktrKranz> just I hadn't time to follow it
[10:29] <Quintasan> dholbach: I want to ask a question, it's related to yesterday's talk. Can I /msg you?
[10:37] <dholbach> Quintasan: sure
[10:41] <Quintasan> s the diffrence between Fix Commited and Fix Released?
[10:41] <Quintasan> crap :S
[10:42] <directhex> fix committed means the fix is published "somewhere". fix released means the fix is in a package in the archive in the right place
[10:42] <directhex> fr'example it might be fixed in a package's bzr branch or svn repo, but not yet pushed to a new package
[10:48] <RAOF> directhex: When's the mono packaging session tomorrow?
[10:48] <Quintasan> directhex: thanks
[10:49] <directhex> RAOF, it's at 8pm utc tonight
[10:49] <directhex> RAOF, you can translate that into foreign
[10:50] <RAOF> Ok, that's 7am at GMT+11.
[11:24] <ScottK> milli: It's mid feb.  Let me know about Rails.  I'd be glad to sponsor it.
[13:31] <morgs> Please remind me: I want to update a package to a new upstream version. What do I attach to the LP ticket: debdiff, or diff.gz?
[13:32] <dholbach> morgs: diff.gz, the debdiff is not really helpful, as it contains all the new upstream changes as well :)
[13:32] <morgs> dholbach: and a pointer to the upstream tarball, right?
[13:32] <dholbach> that'd help, if the package does not have a debian/watch file
[13:33] <morgs> dholbach: the upstream tarball is a tar.bz2 - I can put an orig.tar.gz somewhere, would that be better?
[13:33]  * dholbach hopes to do do some sponsoring during the Jam in Berlin later on
[13:33] <james_w> morgs: no need really, re-compressing a tarball is easy to do
[13:33] <morgs> OK, thanks
[13:34]  * dholbach nods towards james_w
[13:34] <dholbach> I personally always check the contents of the new proposed tarballs anyway
[13:34] <dholbach> one day... one fine glorious day - I know the sun will be shining brightly... we won't have the .orig.tar.gz limiation any more
[13:39] <persia> morgs, Please do have a get-orig-source rule and a README.source if the tarball is being recompressed.
[13:40] <persia> morgs, Also, if you're planning to push the same version also to Debian, and that orig.tar.gz has already been submitted, it's helpful to link to it to avoid any md5sum clashes.
[13:40] <morgs> OK
[13:40] <persia> conversely, if you're submitting to Debian later, and it goes into Ubuntu first, it's helpful to link to the Ubuntu orig.tar.gz for the Debian sponsor.
[13:40] <morgs> OK, thanks
[13:47] <mok0> hyperair: ping
[13:48] <mok0> hyperair, did you see the comments why codelite was rejected?
[13:48] <hyperair> mok0: rejected?
[13:48] <hyperair> mok0: i didn't see anything about it
[13:48] <mok0> hyperair: ah, you didn't :-)
[13:48] <hyperair> where?
[13:48] <mok0> I was rejected by archive-admin
[13:49] <mok0> s/I/It/ :-)
[13:49] <Laney> tsk tsk!
[13:49] <hyperair> eh? but why?
[13:50] <mok0> hyperair: https://lists.ubuntu.com/archives/ubuntu-archive/2009-January/024103.html
[13:50] <hyperair> i see
[13:51] <hyperair> so i make a get-orig-source rule that removes all of that?
[13:51] <mok0> hyperair: you need to repackage the tar-ball, they don't want all that crud in the archive :-)
[13:51] <mok0> hyperair: yes
[13:51] <hyperair> alrgiht
[13:52] <hyperair> and then do i need another two advocates to get it in?
[13:52] <mok0> hyperair: no I'll just re-upload
[13:52] <hyperair> okay
[13:53] <hyperair> basically only the dlls right?
[13:53] <mok0> hyperair: yes, all the binary files that don't belong on Linux
[13:53] <mok0> hyperair: he mentions an .exe file too
[13:53] <hyperair> eh?
[13:53] <hyperair> there is?
[13:54] <hyperair> yeah you're right
[13:54] <hyperair> so there's just dlls and exes?
[13:54] <mok0> I think, yes
[13:55] <mok0> hyperair: but check the tree carefully for irrelevant stuff
[13:59] <hyperair> mok0: there's a .a somewhere
[13:59] <hyperair> do i remove that too?
[13:59] <mok0> yes
[14:00] <mok0> hyperair: If the app doesn't build without it we're in trouble
[14:00] <hyperair> then i start bugging upstream
[14:00] <mok0> hyperair: :-) good boy
[14:01] <hyperair> heh
[14:02] <hyperair> mok0: are .ico files acceptable?
[14:02] <mok0> hyperair: Are they needed for the Linux version of the app?
[14:03] <hyperair> i'm not sure
[14:03] <hyperair> can linux even use .ico files?
[14:04] <mok0> hyperair: Aren't they desktop icon things for Windows?
[14:04] <mok0> hyperair: try getting rid of them & check if it hurts
[14:06] <hyperair> i'll check if they're in the debs
[14:06] <persia> hyperair, .ico files can be read by several applications, but can't be used in .desktop files natively.
[14:07] <hyperair> yeah i thought so
[14:07] <hyperair> but if it's in the source but not the debs is it really required to remove them?
[14:07] <persia> Not usually.  .ico files are sometimes the preferred source for modification.  We certainly have .ico editors in the archive.
[14:08] <hyperair> hm
[14:08] <hyperair> i see
[14:12] <hyperair> mok0: do i need to remove .bat files?
[14:12] <mok0> hyperair: yep
[14:12] <hyperair> and Makefile.win?
[14:12] <mok0> hyperair: everything related to windows
[14:12] <hyperair> *groan*
[14:13] <hyperair> there are so damn many things
[14:13] <mok0> hyperair: Bug upstream ;-)
[14:13] <hyperair> to release a separate source tarball for linux and windows?
[14:13] <mok0> hyperair: yes
[14:13] <mok0> hyperair: many projects do
[14:13] <hyperair> i think that'll require quite a lot of work on his part
[14:13] <hyperair> ._.
[14:14] <hyperair> the last time i tried getting him to do something on that scale, he took ages, and in the end i settled for using symlinks
[14:14] <mok0> hyperair: yeah, probably a bad idea
[14:14] <mok0> hyperair: note down the paths of all the files you remove in a file and make a script to do it
[14:15] <mok0> hyperair: or "find . -name \*.bat -exec rm {}\;
[14:15] <mok0> "find . -name \*.exec -exec rm {}\;
[14:15] <hyperair> mok0: yeah i'll do that, but right now, i'm still trying to get all the files
[14:15] <hyperair> there are dlls, exes, bats, Makefile.win
[14:15] <hyperair> among other things
[14:16] <mok0> hyperair: spread all over the source tree?
[14:16] <hyperair> geez, even pidgin's tarball has windows specific Makefiles in them, why didn't those get removed
[14:16] <hyperair> yes
[14:16] <hyperair> spread all over
[14:16] <mok0> hyperair: file a BTS bug about it :-)
[14:18] <Laney> Huh, isn't the problem just binaries without corresponding source?
[14:18] <hyperair> mok0: what's a BTS?
[14:18] <Laney> There's no need to remove any trace of the windows build
[14:18] <hyperair> oh
[14:18] <mok0> hyperair: Debians Bug Tracking System
[14:19] <hyperair> if it's just binaries without corresponding source, then .exe and .dll and .a should be enough
[14:19] <Laney> right
[14:20] <hyperair> and then what do i call the repackaged tarball?
[14:20] <Laney> if they're needed for the build then they should be created as part of it
[14:20] <hyperair> hoo boy
[14:20] <hyperair> looks like i'm going to ahve to bug upstream
[14:20] <hyperair> he's got a libcurl.a
[14:20] <hyperair> but no libcurl sources
[14:20] <Laney> can it use the system libcurl?
[14:21] <hyperair> lemme grep and see
[14:22] <hyperair> it seems the readme says to install the libcurl dev
[14:22] <hyperair> but ./configure doesn't seem to detect it
[14:22] <hyperair> no wait i found a function inside configure which detects it
[14:23] <hyperair> but it isn't called
[14:24] <hyperair> ah it seems it's a CURL for Windows
[14:24] <hyperair> i think i'll just rm -rf the whole folder than
[14:24] <hyperair> then*
[14:25] <hyperair> ..come to think of it i'm going to try and build without the whole sdk/ folder
[14:29] <mok0> hyperair: yikes that's a miss. You have to call the system curl
[14:29] <hyperair> mok0: no the curl folder seems to belong to windows
[14:30] <mok0> hyperair: ah ok
[14:30] <hyperair> mok0:  in the first placei d on't think it uses curl
[14:31] <mok0> hyperair: just add '~dfsg' to tarball name, after the version no. (That's tilde-dfsg)
[14:31] <hyperair> tilde eh?
[14:32] <hyperair> strange, i thought it was "."
[14:32] <persia> No, please, not tilde.
[14:32] <hyperair> heh
[14:32] <hyperair> .dfsg then?
[14:32] <persia> hyphen is much preferred, or even better, minus-sign.
[14:32] <hyperair> erm
[14:32] <hyperair> is there a difference between minus and hyphen?
[14:32] <mok0> persia: tilde will let any other version override it
[14:32] <persia> Yes.
[14:32] <persia> mok0, Yes, but do we want that?
[14:32] <persia> For dfsg, usually we don't.
[14:33] <Laney> I thought it was +dfsg usually
[14:33]  * hyperair sighs
[14:33] <mok0> persia: if upstream packages a tarball that confirms to dfsg without altering the version no
[14:33] <hyperair> that's very rare isn't it?
[14:33] <persia> Laney, That's common too.
[14:33] <mok0> persia: than you want to be able to override the package and still use the same version
[14:33] <persia> mok0, If upstream does that, they should have versions explained to them.
[14:34] <hyperair> mok0: and in the first place, i don't think he's about to package a dfsg tarball minus version change
[14:34] <hyperair> mok0: his version contains the svn revision stuck on it
[14:34] <hyperair> mok0: that's the 4-digit version after 1.0.
[14:34] <mok0> hyperair: kk
[14:35] <hyperair> persia: heh you know, the author of sigx released a tarball sigx-2.0.tar.bz2 twice, second time, setting a SONAME after i requested him to do so
[14:35]  * mok0 screams in pain
[14:35] <hyperair> lol
[14:36] <hyperair> well considering nobody actually does use sigx yet (i haven't seen any application which uses it, or any distro which packages it), i think that as long as he doesn't do it again it'll be fine
[14:36] <persia> hyperair, I do hope you asked the author to never repeat that, given the nature of web archives.  It breaks namespacing.
[14:36] <hyperair> persia: web archives?
[14:36] <Laney> The old tarball may have been archived elsewhere
[14:37] <hyperair> oh
[14:37] <hyperair> i see
[14:37] <mok0> persia: TBH, that's a problem with Debian's archive structure
[14:37] <persia> hyperair, archive.org for one.  There are others.  Also, there are uncountable caches, both visible and transparent.
[14:37] <mok0> persia: it really OUGHT to be able to handle name-space clashes
[14:37] <ScottK> mok0: Not accepting substitute tarballs with the same version name, but a different md5sum is a feature, even though it's painful.
[14:37] <persia> mok0, It's not archive-specific: it's related to the fact that if two binary blobs have the same name, it causes confusion.
[14:40] <persia> mok0, Yes, the real solution is to rearchitect browserspace to have persistent URNs for all binary blobs, and use URLs as redirectors for URNs, but that idea failed to catch on before the web left CERN years ago, and doesn't show any signs of getting better.
[14:41] <persia> with persistent links between URNs and blobs, adding a cryptographic check doesn't matter, and the archive could just have arbitrary version codes used to reference URNs for packages
[14:41] <persia> (and yes, a text file is also a binary blob, much as a square is also a rectangle)
[14:48] <dholbach> mok0: "primadonnas" :-)
[14:48]  * dholbach sniggers
[14:50] <tritium> Good morning, dholbach.
[14:51] <dholbach> hiya tritium
[14:54] <tritium> dholbach: I'm considering packaging http://ngspice.sourceforge.net/index.html for jaunty, as it has not been in an ubuntu repository since hoary, but I need to check on licensing issues.
[14:56] <rulus> Ik heb de vraag gekregen in welke mate details moeten gekend zijn van de verschillende entiteiten die kunnen voorkomen in het GRB en in de GRB-skeletbestekken.
[14:56] <rulus> GRB-producten: 1. Datamodellering: slide 10 tem 30 --> Is het hier de
[14:56] <rulus> bedoeling dat alle afkortingen en types van elk element gekend zijn?
[14:56] <rulus> En in hoeverre moet dit gedetailleerd gekend zijn? Of is het enkel
[14:56] <rulus> voldoende dat je kort kan zeggen wat alles is?
[14:56] <rulus> De verschillende soorten entiteiten die voorkomen in het GRB dienen gekend te zijn, maar de bijhorende afkortingen en alle mogelijke voorkomende types van een entiteit dienen niet in detail gekend te zijn.
[14:56] <rulus> Van elke entiteit dient er kort toegelicht te kunnen worden om welk object op het terrein het gaat of waar dit kan voorkomen. Daarom moeten niet alle geometrische eigenschappen, uitzonderingen, kenmerken... ten gronde gekend zijn.
[14:56] <rulus> GRB-producten : 4. GRB-GIS: slide 7 tem 29 --> Ook hier, in hoeverre
[14:56] <rulus> moet dit gekend zijn? Is het de bedoeling dat je weet hoe alles in GIS
[14:56] <dholbach> tritium: alright
[14:56] <rulus> voorgesteld wordt?
[14:56] <rulus> Deze slides hoeven niet in detail gekend te zijn. Ze dienen vooral ter illustratie van het GIS-product en tonen een mogelijke voorstelling van de verschillende entiteiten die reeds eerder uitgelegd werden. Qua te kennen leerstof, houden deze slides geen nieuwe elementen in.
[14:56] <rulus> GRB-skeletbestekken : 3. Opbouw: slide 41 tem 141 --> Hoe
[14:56] <rulus> gedetailleerd moet dit gekend zijn? Is het voldoende als je van elk
[14:56] <rulus> element weet wat het juist is en hoe het in een foto wordt
[14:56] <Laney> erm
[14:56] <rulus> voorgesteld? Of moet elk detail gekend zijn?
[14:58] <tritium> dholbach: is there any specific guidance on licenses?  ngspice has a heterogenous license, as it draws from different projects with different licenses, including LGPL, Old BSD, Public Domain, and New BSD.
[14:59] <dholbach> tritium: https://wiki.ubuntu.com/PackagingGuide has a chapter about licenses and debian/copyright
[14:59] <tritium> dholbach: thank you
[14:59] <dholbach> anytime
[15:05] <mok0> persia, ScottK, sorry I had to go AFK for a while
[15:06] <persia> mok0, No problems.  Happens to everyone
[15:06] <mok0> persia: I agree that publishing tarballs with different content but the same name is ... erhh... stupid
[15:07] <mok0> persia: but it happens
[15:07] <persia> Yes, but it shouldn't :)
[15:07] <persia> Anyway, there are lots of ways around it, just not aesthetically pleasing ones.
[15:07] <mok0> persia: I've just reviewed software, where the newest tarball has version 0.6, and an older one 1.0
[15:08] <mok0> persia: the uploader had quite a task writing a watch file :-)
[15:08] <persia> heh, I bet.
[15:09] <persia> perl regular expressions are *very* powerful, but man uscan doesn't provide much of a guide.
[15:09] <mok0> persia: yes, you sometimes have to work to get it to do what you want
[15:10] <mok0> persia: I think we ended up mangling 1.0 to 0.1 or something like that
[15:11] <mok0> persia: us packagers hate upstreams even more than developers hate users ;-)
[15:12] <persia> heh
[15:12] <persia> I'd probably have tried to somehow find the URL near the most recent date, but it might have taken me a week to get it right.
[15:13] <mok0> persia: we considered it, but the date was not systematically written on the web page.
[15:13] <persia> Ugh, even worse.
[15:13] <persia> Some things should just not be.
[15:13] <mok0> persia: and unfortunately, uscan can't get a tarball directly from the URL
[15:13] <mok0> persia: if it contains http://
[15:13] <persia> Needs to scrape a web page?
[15:14] <persia> Yes it can, as long as directory indexing is enabled, and there's no index page.
[15:14] <mok0> persia: I think so, I haven't been able to get the other thing to work
[15:14] <mok0> persia: it ought to be able to work like wget
[15:14] <persia> Uh, no.
[15:15] <persia> I needs a list of versions to compare.
[15:15] <persia> With a single URL, one can only get a single thing.
[15:15] <persia> With a regular expression, one needs to have a set of matching things as a filter.
[15:15] <mok0> persia: of course, d'Oh!
[15:15] <persia> Otherwise, one needs to iterate over the entire matched set, which takes until well after the heat death of the universe.
[15:15] <mok0> :)
[15:20] <ScottK> Still faster than Debian releases.
[15:21] <bddebian> Heya gang
[15:23] <mok0> hi bddebian
[15:23] <bddebian> Hi mok0
[15:24] <tritium> Hi bddebian.
[15:27] <bddebian> Heya tritium!
[15:27] <tritium> :)
[15:29] <ScottK> Heya bddebian.
[15:29] <bddebian> Hi ScottK
[15:32] <tritium> I'm a bit puzzled by bug 246506.  The debian bug status is "Fix Committed", but only because someone has privately packaged it, as far as I can tell.  It's not yet in Debian.
[15:33] <ScottK> tritium: It may be in Debian New too.
[15:33] <tritium> ScottK: I'm not familiar with Debian New.
[15:34] <tritium> Ah, found it.
[15:34] <broonie> tritium: When packages are uploaded to the archive they are initially reviewed for legal problems.
[15:34] <broonie> While that happens they're not downloadable.
[15:34] <ScottK> tritium: After a package is uploaded for the first time it goes into the New package queue (as broonie says)
[15:34] <tritium> broonie: oh, I see.  This one, having multiple licenses, would need that legal review.
[15:34] <tritium> The Debian Import Freeze has passed, correct?
[15:34] <ScottK> http://ftp-master.debian.org/new.html
[15:35] <broonie> tritium: All new packages get this review, you can't tell if the maintainer noticed everything without review.
[15:35] <ScottK> tritium: For auto sync, yes.  They can still be requested manually.
[15:35] <tritium> OK.  I don't find it in http://ftp-master.debian.org/new.html
[15:36] <rulus> I'd like to apologise for my paste earlier; I wasn't aware of the fact that Putty associated the middlemousebutton with paste. Sorry.
[15:37] <tritium> Thanks, broonie and ScottK.  How would you advise I proceed?
[15:38] <ScottK> tritium: You could email the owner of the ITP bug and ask them how soon the plan to upload it.  You might also look on mentors.debian.net.
[15:38] <tritium> It seems that "Fix Committed" isn't appropriate for it, if it's not even in Debian New.
[15:39] <tritium> ScottK: will do.  Can his package be brought into ubuntu directly, or should it come straight from Debian?  Should it be repackaged (by me)?
[15:40] <tritium> In the mean time, I'll contact the bug owner.
[15:40] <ScottK> If it doesn't come through Debian (and given the length of the New queue that's getting unlikely) then it'd have to go through REVU.  You could do that.
[15:40] <ScottK> Ideally they will give you access to the draft package and you don't have to change much.
[15:41] <tritium> ScottK: ok, thanks again.
[15:41] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - Day 4 to kick off in #ubuntu-classroom in 19m. :-)
[15:42] <slytherin> tritium: check with motu science team if they are interested in helping you with ngspice.
[15:43] <tritium> slytherin: I'm technically still the administrator of that team, but I'm no longer MOTU.  I'm not sure the team is still active.
[15:43] <tritium> I've pinged wgrant about it, though.  Thanks.
[15:46]  * ScottK notes mok0 is interestedin science stuff too.
[15:46] <mok0> I am
[15:46] <ScottK> tritium: ^^
[15:46]  * tritium notes above ;)
[15:50]  * mok0 notes his name is no isotope
[15:50] <mok0> s/name/nick
[15:51] <mok0> tritium: the science team is sadly inactive
[15:52] <tritium> mok0: yes, if I pursue reinstatement as an MOTU again, I'd hope to focus on that team.
[15:52] <mok0> tritium: cool
[15:52] <mok0> tritium: the Debian science team is much more active
[15:52] <tritium> mok0: are you part of that?
[15:53] <mok0> tritium: yes
[15:53] <tritium> mok0: excellent
[15:53] <tritium> Have you seen anything about ngspice in particular on your mailing list or otherwise?  It's licensing is peculiar.
[15:53] <mok0> tritium: No, I haven
[15:54] <mok0> t
[15:54] <tritium> ah
[15:54] <slytherin> tritium: you may want to contact tuxmaniac. Although he is not MOTU, he is very enthusiastic about electronic related softwares.
[15:54] <mok0> tritium: can I see it somewhere? URL?
[15:54] <tritium> slytherin: oh, thanks for the tip.
[15:55] <mok0> tritium: and norsetto
[15:55] <tritium> mok0: debian bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489768
[15:56] <tritium> project page here: http://ngspice.sourceforge.net/
[15:59] <mok0> "The group developing ngspice has written to Berkeley's copyright holders asking to change the license to the new BSD, which has the incompatibility removed, but without success. "
[15:59] <mok0> I wonder if that means they refused, or that they didn't answer the request
[16:01] <tritium> Not sure.  Here's the COPYING file from the new ng-spice-rework-18 package that talks about the "heterogenous
[16:01] <tritium> " license: http://paste.ubuntu.com/108277/
[16:03] <mok0> tritium: OMG
[16:04] <tritium> mok0: pretty crazy, eh?
[16:05] <mok0> tritium: yeah
[16:06] <tritium> It seems I always pick the crazy stuff to try to package.
[16:07] <mok0> tritium: If UC decided to remove the advertising clause from their license, why wouldn't they accept that the old BSD license be changed in this case? It doesn't make sense
[16:08] <tritium> I agree.
[16:10] <mok0> tritium: it's the crazy stuff out there that left...
[16:10] <tritium> heh
[16:15] <mok0> ScottK, you want me to fake-sync ktranslator?
[16:15] <ScottK> Got to.
[16:15] <ScottK> Different orig.tar.gz
[16:15] <mok0> ScottK, how did that happen?
[16:17] <mok0> ScottK, problems with debian's repo?
[16:20] <ScottK> mok0: It's hard to say.  Sometimes upstream tarballs get published more than one place.
[16:20] <ScottK> mok0: It's not rare the first time we try to sync from Debian.
[16:21] <mok0> ScottK, this looks to be a new packaging, they didn't use the old ubuntu one
[16:21] <ScottK> This is not unusual either.
[16:21] <ScottK> So the trick is to see if there is any needed to be saved from our.
[16:21] <ScottK> our/ours.
[16:21] <mok0> ScottK, yes
[16:21] <mok0> ScottK, I will take care of it
[16:22] <ScottK> If so, then merge, but unless it's significant, just fakesync.
[16:22] <ScottK> Great.
[17:28] <mok0> ScottK, hrmph, ktranslator is a KDE3 program, and hasn't been updated in almost  3 years
[17:29] <ScottK> mok0: Does it need more than kdelibs?
[17:29] <mok0> kdelibs4-dev
[17:30] <ScottK> Then it's at least usable for now.
[17:31] <mok0> ok, I'll continue. /me is annoyed at this package because it doesn't build out of the box. I thought I checked that
[17:31] <soc> hi
[17:31] <soc> just wanted to say thank you for all your help getting ttf-droid into ubuntu!
[17:31] <mok0> soc: you
[17:32] <soc> it looks like it was included 2 days ago and is now generally available through synaptic after install
[17:32] <mok0> soc, you're welcome
[17:32] <soc> ah hi mok0!
[17:32] <soc> without you help i wouldn't have gotten my package into the shape it is now ..
[17:32] <hyperair> mok0: i've uploaded a new tarball of codelite to revu, along with the necessary changes regarding get-orig-source
[17:32] <hyperair> mok0: could you take a look?
[17:33] <mok0> hyperair: yes I'll take a look, after I've cracked the problem I am looking at ATM
[17:33] <hyperair> mok0: is it something i could help with?
[17:34] <mok0> hyperair: you mean you want to swap :-)
[17:34] <hyperair> eh?
[17:34] <hyperair> swap?
[17:34] <mok0> hyperair: I take codelite and you take ktranslator...
[17:34] <mok0> hyperair: I'll have it nailed soon
[17:35] <mok0> hyperair: It's a configure file built in maintainer-mode, so once the build goes "make" it decides to update everything
[17:37] <mok0> which is a pain
[17:41] <hyperair> ah i see
[19:12] <fransman> Can someone check there a updated package of flumotion in the cue.
[19:14] <fransman> I already did create a bug ticket for it, https://bugs.launchpad.net/ubuntu/+source/flumotion/+bug/319204
[19:21] <directhex> woo, mono session in classroom soon :o
[19:30] <Chris`> If there are many reviewers/advocates free, can you please review one of my packages? - http://revu.ubuntuwire.com/details.py?package=grdc
[19:33] <hyperair> nobody seems free these days =(
[19:34] <Chris`> hyperair: I know I try daily for reviews :p
[19:34] <Chris`> So much for aiming for the MOTU :p
[19:34] <hyperair> i've got three outstanding packages
[19:34] <jpds> Chris`: Does perl have to be in the build-deps?
[19:34] <jpds> hyperair: lies...
[19:34] <hyperair> jpds: fine, you're the only one free =p
[19:34] <Chris`> jpds: Yeah isn't it included?
[19:34] <hyperair> why does everyone ignore me then T_T
[19:34] <Chris`> It's for the pod manpage
[19:34] <Chris`> hyperair: jpds is my mentor, it's his duty ;)
[19:35] <hyperair> aah
[19:35] <hyperair> i should go and apply for mentoring as well
[19:35] <hyperair> =\
[19:35] <hyperair> how dyou apply?
[19:35] <jpds> Chris`: I think perl gets pulled it anyway (it's what most of the dh_* scripts are written in).
[19:35] <Chris`> jpds: I was told on the manpage tutorial to include Perl
[19:35] <hyperair> a standard pbuilder login has perl installed
[19:36] <Chris`> hyperair: https://wiki.ubuntu.com/MOTU/Mentoring/Junior_Contributor
[19:36] <jpds> Chris`: Hmm, ok. Did you know that you can seperate paragraphs in the long desc by have a " ." line?
[19:37] <Chris`> A what line?
[19:37] <jpds> As in: apt-cache show ubuntu-dev-tools
[19:37] <Chris`> Oh cool ok
[19:38] <Chris`> *changed*
[19:38] <Chris`> Anything else bad?
[19:38] <jpds> Chris`: Does the applet have to be called: grdc-gnome? Sounds a bit.. vague.
[19:38] <Chris`> jpds: That's what upstream called it :-/
[19:39] <Chris`> Should I mix it up or leave it as upstream wishes it to be?
[19:39] <jpds> irssi-otr is know as irssi-plugin-otr in Debian..
[19:39] <hyperair> damn, i seriously need to write a wiki page about myself?
[19:40] <Chris`> hyperair: I have :P
[19:40] <Chris`> hyperair: http://wiki.ubuntu.com/Chris
[19:40] <hyperair> thanks
[19:40] <hyperair> 17!
[19:40] <hyperair> damnit you're younger than me
[19:40] <Chris`> jpds: Perhaps grdc-gnome-applet?
[19:41] <hyperair> then there's always rainct -- a year younger than me, same amount of years using linux, and motu already!
[19:41] <Chris`> hyperair: I'm just using it as a progress tracker, more like a blog
[19:41] <hyperair> i see
[19:42] <jpds> Chris`: Not too sure, can't find a Debian GNOME policy on it.
[19:42] <Chris`> Safer to leave it as it is? :-/
[19:42]  * jpds would like gnome-applet-grdc, but can't find any packages which follow that.
[19:44] <Chris`> So other than the line break, anything worth changing?
[19:44] <jpds> Chris`: Would be nice to Suggest: the applet package.
[19:44] <Chris`> Ah, how does one go about that?
[19:44] <Chris`> Suggests: package?
[19:45] <jpds> Yep.
[19:45] <Chris`> *changed*
[19:48] <Chris`> I've uploaded the new grdc now
[19:52] <Chris`> jpds: it's uploaded now if you wanna add a comment/avocation :D
[19:55] <RainCT> hyperair: and jpds is even younger \o/
[19:58] <hyperair> RainCT: aren't you born in 1991?
[19:59] <RainCT> hyperair: yep
[19:59] <hyperair> RainCT: so is jpds
[19:59] <hyperair> and me in 1990
[19:59] <hyperair> the end of it
[20:00] <RainCT> hyperair: but there are some months between his and my birthday (which, btw, is in 2-3 weeks :D)
[20:00] <hyperair> heh.
[20:00] <hyperair> there are three months between yours and mine
[20:02]  * ScottK has children born in 1991.  Urgh.
[20:02] <jpds> RainCT: Can you poke grdc, looks good to me.
[20:02] <ScottK> Child anyway
[20:02] <RainCT> jpds: bad tab completion :P
[20:02] <hyperair> ScottK: heheheh
[20:02] <RainCT> lol
[20:02] <laga> i feel old.
[20:02] <laga> and i haven't become a MOTU yet ;)
[20:02] <RainCT> ScottK: tell them to become MOTU :P
[20:03] <hyperair> laga: awesome. let's race =p
[20:03] <Chris`> Count me in!
[20:03] <directhex> mono session now on! gogogo :p
[20:03] <hyperair> Chris` no fair you've got a headstart =p
[20:03] <laga> hyperair: how old are you? ;)
[20:03] <ScottK> RainCT: No, they aren't that interested in computers.
[20:03] <hyperair> laga: born 1990. i'm lazy to remember my age, or do the calculation
[20:03] <ScottK> My best hope is the 5 year old.
[20:03] <RainCT> directhex: is that a treath?
[20:04]  * RainCT runs
[20:04] <Chris`> I lied I'm actually 17 in a week but there's no point updating the wiki just for that
[20:04] <laga> hyperair: ah. i'm turning 22 this year, so i guess i'll have to lose.
[20:04] <hyperair> directhex: would you be so kind as to review a mono package for me? =p
[20:04] <directhex> RainCT, yes
[20:04] <directhex> hyperair, after the session, sure
[20:04] <directhex> hyperair, you can ask meebey, even! he's the debian mono pope!
[20:04] <hyperair> directhex: http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin thanks =p
[20:05] <RainCT> directhex: so you agree that mono is evil? \o/     :P
[20:05] <directhex> RainCT, yeah, but less evil than java
[20:05] <RainCT> hehe
[20:06]  * ScottK hugs his Python.
[20:06] <laga> how's java moar evil?
[20:06] <hyperair> directhex: agreed!
[20:06] <hyperair> laga: because java is longwinded and stupid
[20:06] <ScottK> laga: How much mono stuff in multiverse?
[20:06] <laga> i actually like java. :)
[20:06] <directhex> laga, because java lacks monkeys
[20:06] <directhex> ScottK, none
[20:06] <hyperair> laga: if you've got a good IDE, yeah it isn't that bad
[20:06] <laga> ScottK: uh, dunno.
[20:06] <ScottK> directhex: Yep.
[20:07] <laga> hyperair: i like eclipse. i wish there was a nice debugger for python (is there o ne?)
[20:07] <ScottK> laga: How much java stuff stuck in multiverse?
[20:07] <hyperair> laga: but when you're writing it on paper, you tend to hate SuperLongAndObscureNamespaces.SuperLongAndObscureSecondNamespace.SuperLongClassName
[20:07] <laga> ScottK: just wait for icedtea :)
[20:07] <directhex> why are none of you in #ubuntu-classroom then? :o
[20:07] <laga> hyperair: well, that'd be silly.
[20:07] <ajmitch> directhex: because we're sensible people
[20:07] <ajmitch> (and I just joined)
[20:07] <hyperair> laga: it's a written paper exam
[20:07] <laga> hyperair: actually, we will have an oral examination for this java class. :)
[20:08] <hyperair> oral?!
[20:08] <laga> hyperair: yes. :)
[20:08] <hyperair> i thought written programming was stupid, but oral sounds even more stupid ._.
[20:08] <laga> hyperair: heh. no, it'll be more about algorithms.
[20:08] <hyperair> System dot out dot printf open bracket ...
[20:09] <fransman> how do i set bug #319204 for need packaging ?
[20:09] <hyperair> doesn't seem like a need packaging bug
[20:09] <laga> hyperair: it'll be more more high-level stuff.
[20:09] <laga> hyperair: we implemented stuff like parsers and they probably want us to describe that
[20:09] <hyperair> laga: then that's fine i guess, but oral still sounds weird. don't programmers draft things out on paper for complex issuse?
[20:09] <laga> hyperair: we'll have time for that i suppose.
[20:10] <fransman> hyperair: what does it then?
[20:10] <laga> hyperair: AFAIR, we will also be graded on the home work we turned in. we did projects instead of lectures. the oral exam is just a bonus IIRC
[20:11]  * directhex thinks hyperair could learn useful things in this session
[20:11] <hyperair> directhex: eh wha?
[20:12] <directhex> hyperair, session on mono packaging in #ubuntu-classroom
[20:12] <directhex> that's better!
[20:12] <hyperair> it seems...quiet
[20:12] <RainCT> directhex: is that transition also on Debian?
[20:13] <directhex> gnome#? ehm... sort of. the offending gnome# is in experimental, but we're not currently building things against it
[20:13] <directhex> poke slomo for that
[20:19] <khashayar> §
[20:21] <khashayar> Hi all. I've built a package for pencil (http://www.les-stooges.org/pascal/pencil/), and I'm currently down to only one lintian warning, missing man page. Is it frowned upon to upload it to revu in its current state? (I'm just not going to do the man page tonight).
[20:22] <RAOF> khashayar: You're welcome to upload to revu and solicit comments about the rest of the packaging.
[20:22] <khashayar> RAOF: Thanks. I'll do that.
[20:23] <RAOF> khashayar: Make sure to add a comment to the effect that you're not after advocation, just comment, and you'll write the man page before asking for it to be uploaded.
[20:23] <hyperair> khashayar: i generally upload to revu whenever i've gotten some major changes done, and only when i've fixed all my lintian stuff i start asking for comments
[20:24] <khashayar> hyperair: OK. So suggest I write the manpage first before uploading?
[20:24] <hyperair> khashayar: just upload first
[20:24] <hyperair> khashayar: you can always reupload if you make changes
[20:25] <khashayar> hyperair: OK. Thanks.
[20:25] <hyperair> revu-ers seem so scarce that if you upload within a week or so of your previous upload you're almost bound to get no comments, unless you've bugged someone to do so
[20:31] <Chris`> hyperair: Talking of bugging... RainCT you there? :)
[20:32] <hyperair> Chris`: ?
[20:32] <RainCT> Chris`: yes, but I'm busy :(
[20:32]  * Chris` bugs RainCT for just one more advocate
[20:32] <Chris`> OH ok don't matter
[20:49] <mok0> hyperair, you are right, revuers are very scarce. There's less than a handful of MOTUs that do any work there
[20:49] <mok0> hyperair: looking at codelite now, btyw
[20:49] <hyperair> mok0: ah thanks =)
[20:49] <wgrant> tritium: Yes, we are rather completely inactive. I see no problem with you remaining an admin.
[20:50] <tritium> wgrant: Thanks.  :)  You realize my MOTU-ship expired, though, right?
[20:50] <wgrant> tritium: I do.
[20:51] <tritium> wgrant: Thanks.  :)
[20:51] <hyperair> MOTU-ship expires?
[20:51] <RainCT> hyperair: you can renew it clicking on a link
[20:51] <tritium> hyperair: on launchpad, I didn't renew in time
[20:51] <hyperair> i see
[20:51] <RainCT> mok0: btw, I wanted to tell you something..
[20:52] <RainCT> mok0: you rock!! :P
[20:52] <mok0> RainCT: heh
[20:52]  * hyperair thinks so too
[20:52] <tritium> wgrant: please don't hesitate to ask me to help out, if there's something you need done
[20:52] <mok0> Thanks guys
[20:52]  * tritium just met mok0 today, but would agree that he rocks :)
[20:54] <hyperair> mok0, your friendly neighbourhood buildd ;)
[20:55]  * Chris` has silently observed mok0 over the past week and thinks given enough time, he may fall in love with mok0 :(
[21:01] <hyperair> lol
[21:14] <mok0> hyperair: I can't see where you do the repackaging of the tarball
[21:14] <hyperair> mok0: debian/rules
[21:14] <hyperair> mok0: and debian/copyright, see X-something
[21:15] <mok0> hyperair: in the clean target?
[21:15] <hyperair> mok0: get-orig-source
[21:15] <hyperair> there should be a target
[21:15] <hyperair> after clean
[21:15] <mok0> uh, I may have the wrong version here
[21:15] <hyperair> lol
[21:15] <hyperair> http://revu.ubuntuwire.com/revu1-incoming/codelite-0901221833/codelite_1.0.2674+dfsg-0ubuntu1.diff
[21:16] <hyperair> heheheheheg
[21:18] <mok0> hyperair: got it now
[21:19] <hyperair> okay
[21:42] <hyperair> mok0: could you look at this please? i've fixed the stuff you mentioned in your previous comment http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[21:50] <tdomhan> can the merge-o-matic not be used after the DebianImportFreeze?
[21:51] <pochu> tdomhan: it can, but you need a good reason to perform a merge
[21:51] <pochu> bug fixes are good reason, btw ;)
[21:58] <tdomhan> so MOM still checks for new versions in the debian repos? because I can't find any files of the package I'm interested in, mhhhh or indicates this, that the packages is being synced? mhh
[22:09] <hyperair> mok0: thanks
[22:11] <hyperair> jpds: you free for a review? =p
[22:11] <jpds> hyperair: About to go to bed, what is it so I can look at it in the morning?
[22:12] <mok0> hyperair: got another batch of comments for you
[22:13] <tdomhan> it's about the package gpsbabel, in the current debian unstable repo it is version 1.3.6-3, the jaunty version is 1.3.5. shouldn't merge-o-matic create it's corresponding files?
[22:13] <hyperair> jpds: http://revu.ubuntuwire.com/details.py?package=sigx
[22:13] <hyperair> jpds: and http://revu.ubuntuwire.com/details.py?package=vazaar
[22:13] <hyperair> mok0: ah i saw, thanks
[22:13] <hyperair> mok0: should i document it in codelite then?
[22:14] <mok0> hyperair: I've already uploaded. Let's see if it gets into the archive this time. If it does, you can prepare an update of the package fixing that
[22:14] <jpds> hyperair: OK; will look at both when I can tomorrow morning.
[22:15] <hyperair> jpds: thanks
[22:15] <hyperair> mok0: okay
[22:15] <hyperair> mok0: then how do i submit it?
[22:16] <hyperair> mok0: also the get-orig-source issue seems to happen only if you've already got an orig tarball
[22:16] <mok0> Normally, you prepare a debdiff and get that sponsored through LP
[22:17] <mok0> hyperair: let's worry about that later
[22:17] <hyperair> okay
[22:18] <hyperair> mok0: by the way, regarding the get-orig-source target... how should i fix it? uscan refuses to download again if it detects a orig.tar.gz of the correct version
[22:19] <mok0> Yikes 129 packages awaiting review... that's +19 from a week ago.
[22:19] <mok0> hyperair: ah, is that what happens?
[22:20] <hyperair> mok0: yes
[22:21] <hyperair> mok0: otherwise it works.
[22:21] <hyperair> mok0: perhaps i should just put &&?
[22:21] <mok0> hyperair: I'd suggest not calling uscan in the target
[22:21] <hyperair> why not?
[22:21] <hyperair> mok0: ^
[22:21] <mok0> hyperair: than you'd have to do that first, and wouldn't need to run get-orig-source
[22:22] <hyperair> what?
[22:22] <hyperair> do uscan first?
[22:25] <mok0> hyperair: yeah, so the operator would have to run it manually.
[22:26] <mok0> hyperair: perhaps, in the get-orig-source target, you could run a uscan --report-status, if the version is up-to-date, bail out
[22:27] <mok0> hyperair: nice little problem to keep you awake tonight
[22:28] <hyperair> mok0: more like this morning
[22:28] <hyperair> mok0: it's 6.30AM and the sun's going to rise soon
[22:29] <hyperair> mok0: anyway the operator doesn't have to run uscan manually. in fact, it's better if uscan wasn't called manually
[22:29] <mok0> hyperair: oh... did you get up early, or didn't you get to bed?
[22:29] <hyperair> haven't gone to bed yet
[22:29] <hyperair> class at 12.30PM
[22:29] <mok0> yikes
[22:29] <hyperair> and i'm multitasking between some packages and an accounts tutorial =p
[22:30] <mok0> phew
[22:30] <hyperair> i'm trying to get this done so i don't have to travel half the country with the textbook this weekend (i'm heading back home for chinese new year)
[22:31] <hyperair> anyway about the lintian error
[22:31] <hyperair> i figured out what's wrong
[22:31] <mok0> hyperair:  the dll one?
[22:31] <hyperair> dh_clifixperms wasn't being called because i hooked it onto common-binary-predeb-arch, instead of -indep
[22:31] <hyperair> yeah the dll one
[22:31] <mok0> hyperair: ah, good!
[22:31] <hyperair> yep
[22:32] <hyperair> so i've fixed that issue.. and the copyright issue..
[22:32] <hyperair> just add dots right/
[22:32] <mok0> yep
[22:32] <mok0> simple
[22:32] <hyperair> hmm come to think of it codelite's didn't have dots
[22:32] <hyperair> and then about the get-orig-source..
[22:32] <mok0> hyperair: I missed that, dang
[22:32] <hyperair> heheh
[22:32] <hyperair> i'll jhave to fix that in all of my other revu packages
[22:33] <mok0> great, thanks. It's not a problem yet, because copyright is in principle free-format
[22:33] <hyperair> yeah
[22:33] <hyperair> well lintian will start complaining later on
[22:34] <hyperair> on a side note.. what do i do about the issue with uscan?
[22:34] <mok0> But if you choose the machine-readable format, it should of course be correct. It's just, there's no software to check it yet
[22:34] <hyperair> it dies when there's a tarball existing
[22:34] <hyperair> otherwise it works
[22:34] <mok0> hyperair: of course you could rm -f the tarball first :-P
[22:34] <hyperair> if you rm the ../bansheelyricsplugin_0.6.orig.tar.gz
[22:34] <hyperair> hmm
[22:35] <hyperair> would that be a good idea?
[22:35] <hyperair> hmmm
[22:35] <hyperair> yeah i think i should do that
[22:35] <hyperair> which means yet another change to implement for codelite as well
[22:35] <hyperair> the error happens there too
[22:35] <hyperair> lool
[22:35] <mok0> hyperair: what about uscan --report can you use that first ?
[22:35] <hyperair> nope
[22:35] <hyperair> that one reports the status as up to date as long as your debian/changelog has the said version
[22:35] <mok0> uscan is not really advanced enough
[22:36] <hyperair> it's pretty cool already
[22:38] <mok0> hyperair: yes, but it should be more scriptable
[22:39] <hyperair> yeah
[22:39] <hyperair> true
[22:39] <hyperair> the --report thing isn't exactly very parseable
[22:39] <hyperair> though --dehs is scriptable
up to date</status>
[22:40] <hyperair> with the use of grep and sed, you could extract that out
[22:40] <mok0> hyperair: yes that could be done
[22:41] <hyperair> yeah but it reports up to date as long as your debian/changelog has an up to date version
[22:41] <mok0> hyperair: but why haven't I seen this problem before?
[22:41] <hyperair> why..
[22:41] <hyperair> probably because they used wget?
[22:42] <hyperair> also according to the bpp, get-orig-source must be callable from any directory.
[22:42] <hyperair> it's entirely possible that they didn't provide for that
[22:42] <mok0> hyperair: put a dh_checkdir call in it
[22:42] <hyperair> anyway i've uploaded another version
[22:42] <hyperair> what's dh_checkdir?
[22:43] <hyperair> there isn't a manpage
[22:43] <hyperair> command not found. hmm
[22:43] <mok0> dh_testdir sorry
[22:43] <hyperair> ah that
[22:44] <hyperair> i don't see any real application for it in get-orig-source
[22:44] <mok0> hyperair: it makes sure you only call the script from $topdir
[22:45] <hyperair> mok0: but you're supposed to be able to call it from other directories
[22:45] <hyperair> mok0: and it's supposed to dump the orig.tar.gz into your current directory, no matter waht it is
[22:45] <mok0> hyperair: that way it will work right no matter what dir it's called from :-)
[22:46] <hyperair> =\
[22:46] <mok0> uscan will drop it in $topdir/..
[22:46] <hyperair> yeah
[22:47] <hyperair> uscan drops it in $topdir, and then get-orig-source does its fancy stuff wherever it likes, dumps your resulting orig.tar.gz into your current dir, and then cleans up
[22:49] <hyperair>    This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory.
[22:49] <hyperair>  This target may be invoked in any directory, and should take care to clean up any temporary files it may have left.
[22:49] <hyperair> there we go
[22:50] <mok0> hmm
[22:50] <hyperair> mok0: anyway there's a new upload
[22:50] <mok0> hyperair: ok thanks
[23:02] <hyperair> my my what a pretty sunrise
[23:02]  * hyperair yawns
[23:06] <tritium> Hello.  If my launchpad team membership expired, is there a way to reactivate it?  I understand that MOTUs can activate/deactive themselves now?
[23:07] <mok0> tritium: AFAIK you need to apply for MOTUship once more
[23:07] <mok0> tritium: Of course you could try writing MC asking to have your MOTUship reactivated
[23:08] <tritium> mok0: I may do that.  You're not aware of any changes to the team membership rules to allow activating/deactivating at will, as schedules permit?
[23:08] <mok0> tritium: no
[23:09] <tritium> mok0: ok, thanks.
[23:12] <hyperair> mok0: i need to document the repackaging in debian/changelog?
[23:13] <hyperair> mok0: i thought it was only necessary in debian/copyright
[23:15] <mok0> hyperair: it's a bit confusing. Honestly, I don't think it logically belongs in copyright, but it's in the policy.
[23:15] <maco> is it intentional that there's no spim in jaunty, or has it just not been gotten around to yet?
[23:15] <mok0> hyperair: however, if it's in changelog, it's certain to be noticed by other people who come along and do stuff to the package
[23:15] <hyperair> mok0: i see. okay then. there's a new upload
[23:16] <mok0> hyperair: f.ex. if upstream suddenly provides a tar.gz file, it is good to be able to see there what you did
[23:16] <hyperair> mok0: ah. right.
[23:16] <mok0> hyperair: if you promise to go to bed, i will ack it :-)
[23:17] <hyperair> mok0: heh yeah i'll go to bed now
[23:17] <maco> oh....its not in intrepid either. what happened to spim?
[23:17] <hyperair> good uh morning
[23:18] <mok0> heh
[23:18] <mok0> Midnight here, I gotta go soon too
[23:18] <hyperair> heh.
[23:18] <mok0> Have to get up early
[23:18] <tritium> Good night, mok0.
[23:18] <hyperair> bye
[23:36] <Chris`> mok0: Thanks for that mail to the mailing list :D