[00:01]  * Hobbsee blecks at that 'diff' containing the entire source code and debian/ of the project.
[00:03] <jsmidt> I've been reading https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate to learn how to update a package.  After I update the package do I make a bug on launchpad?  The howto doesn't say.  Should I subsribe the universe sponsors?
[00:03] <shenron> hello, I am currently trying to get some software I wrote into ubuntu. Is it important to use make for compiling? Currently it compiles using a script which runs a few g++ commands (its a fairly simple compile), but if I want it packaged for ubuntu should I switch to make?
[00:04] <shenron> I was directed to ask that question here by someone in #ubuntu, btw.
[00:05] <raof> shenron: It's not important to use make at all; all that's required is that it builds from source, and this build can be automated.
[00:05] <shenron> oh ok, so since there is a script that builds it that should be fine?
[00:05] <raof> jsmidt: Yes, you make a bug on launchpad, attaching the new diff.gz
[00:05] <raof> shenron: Right.
[00:06] <shenron> w00t, awesome. should I include an installer which will put something in /usr/bin as well?
[00:06] <jsmidt> raof, thanks.
[00:06] <jsmidt> raof, do I need to kink to the new orig tarball?
[00:07] <jsmidt> link
[00:07] <raof> shenron: That's generally nice for other distros, but is not absolutely necessary.
[00:07] <raof> jsmidt: No; have a watch file that works ;)
[00:07] <shenron> alright, thanks raof
[00:23] <porthose> maxb: thx. shot myself in the foot with that one hehe
[00:23]  * porthose goes and fixes
[00:34] <maxb> porthose: see comments on REVU, sorry, I've given you a lot to think about :-)
[00:43] <jsmidt> I have a debian rules file with a slice command.  What is that?  Pbuilder is complaining slice: Command not found.
[00:45] <maxb> jsmidt: Try 'dpkg -p slice'
[00:45] <maxb> Though clearly the package is wrong if it uses a command and doesn't Build-Depend on it
[00:48] <jsmidt> maxb, it does build depend on slice.  Yet, right off the bat I get this error
[00:50] <maxb> hrm, peculiar
[00:50] <maxb> that doesn't make any sense :-/
[00:50] <jsmidt> ya
[00:50] <maxb> do you want to pastebin a buildlog?
[00:52] <jsmidt> maxb, http://pastebin.com/d3b659090
[00:53] <maxb> Ohhhh
[00:53] <maxb> See line 14
[00:53] <jsmidt> ya
[00:53] <jsmidt> What warning is that?
[00:54] <maxb> unmet build-deps
[00:54] <jsmidt> I thought pbuilder took care of adding build-depends
[00:55] <maxb> pbuilder has two modes, in the mode you're running it in, it builds a source package *outside* the chroot, copies(?) the source into the chroot environment and builds it
[00:56] <jsmidt> How do I run the other mode? I typed "pdebuild " which has seemed to work with everything else.
[00:57] <maxb> --use-pdebuild-internal. The man page warns "This option will not protect the working directory and its parent directories from the build scripts." I get why it doesn't protect the working dir, since it's being bindmounted into the chroot. I don't understand how the parent dirs would be visible, though
[00:58] <maxb> unless you can actuall ../../ up out of a bindmount!?
[00:58] <jsmidt> weird
[01:00] <raof> jsmidt: The problem is that slice is required for the clean target; IE: you need slice to build the _source_ package.
[01:00] <jsmidt> okay
[01:24] <hyperair> does anyone here have experience making a program link with xulrunner?
[01:27] <raof> hyperair:  asac does.
[01:31] <hyperair> asac: ping
[01:31] <hyperair> raof: thanks
[02:53] <jsmidt> Is there any documentation for interacting with Lanuchpad over the command line?  Open/closing bugs, adding attachments, etc... Do I have to use the web interface?
[02:53] <raof> You can use gpg-signed mail.
[02:54] <jsmidt> Okay, is there documantaion for how to open a bug using mail for example?
[02:56] <raof> Yes.  There's a page on launchpad, or you can email help@bugs.launchpad.net, I think, to get an automated thingy.
[02:58] <jsmidt> raof, thanks, I think I have found it.
[03:06] <xnox> Do I need to write patch description anywhere? Changelog?
[03:10] <raof> You do need to write a patch description _somewhere_.  If you're using dpatch, I'd stick it in the dpatch header.
[03:10] <raof> You also need to describe what the patch _does_ in changelog.
[03:10] <xnox> raof: simple-patch-sys?
[03:10] <xnox> raof: patch comments on top + changelog?
[03:11] <raof> That should be OK, yeah.
[03:11] <hyperair> raof: is it required for initial releases?
[03:12] <raof> Is what required for initial releases?
[03:12] <hyperair> entries in changelog regarding patches
[03:14] <ScottK> hyperair: Yes.  All patches should be documented.
[03:14] <hyperair> ScottK: even if there's a header?
[03:14] <ScottK> hyperair: Yes.
[03:15] <hyperair> i see
[03:15] <hyperair> on a side note, if i've got a package which requires *-gtkmozembed, which package should i b-d on?
[03:16] <hyperair> i tried using libxul-dev, but it seems that it's an older version of xulrunner
[03:16] <hyperair> xulrunner-1.9-dev refuses to be compiled without -R in LDFLAGS
[03:20] <raof> xulrunner-1.9-dev is, I believe, the right header.
[03:20] <raof> s/header/package.
[03:31] <toresbe> OT: Are there any doxygen-literate people here? I'm faced with a problem and I don't know where to ask it.
[03:32] <toresbe> I've been asked to fix up some PHP files (ugh) and I'm doxygenizing them now. For *one* of the files, a completely unremarkable file, it is refusing to document the functions (but not the @file).
[03:34] <toresbe> (The line endings are the same, BTW.)
[03:39] <hyperair> raof: but the libraries are all in /usr/lib/xulrunner-1.9.0.5/, and ld can't find them to link without -R. if i chrpath -d the executable after compiling, ld can't find the library to link with
[03:39] <raof> hyperair: That's right.  You either need a wrapper that sets LD_LIBRARY_PATH, or you need a RPATH.
[03:40] <hyperair> raof: i'd leave the RPATH intact, but it seems that debian policy doesn't allow it
[03:40] <toresbe> If anyone feels like taking a look, the file is here: http://gunkies.org/stuff/problematic_php.txt
[03:40] <raof> hyperair: There's a _reason_ the world + their dog is moving to embedding webkit rather than gecko.  Gecko is a pain in the arse.
[03:40] <toresbe> It sees the function, but not my comments.
[03:42] <hyperair> raof: you don't really have a choice if the package only has support for embedding gecko
[03:42] <hyperair> well there's the choice of not embedding it at all
[03:42] <hyperair> i mean not packaging it at all
[03:43] <raof> Right.
[03:44]  * hyperair grumbles
[03:44] <hyperair> i thought patching the thing to use gtksourceview2 instead of 1 was the end of my problems
[03:44] <hyperair> at least it compiles with libxul-dev
[03:44] <hyperair> and runs. just that you get the old chiselblock interface that reminds you of firefox 2
[04:33] <fabrice_sp> Hi. When fixing a FTBFS, should I also fix warnings in lintian? Or I should just patch the FTBFS? It's for openmovieeditor in jaunty
[04:35] <fabrice_sp> (I'm getting warning/errors on watch file, out-of-date standard 3.7.2 and  build-depends-on-obsolete-package
[04:35] <fabrice_sp> )
[04:36] <ScottK> fabrice_sp: Standards version you should not change at all.
[04:36] <ScottK> There is Ubuntu Policy on that.
[04:36] <ScottK> Fixing the watch file and build-dep-on-obsolete package (make sure it works with the new one) are both good.
[04:36] <ScottK> Those are also changes that should go back to Debian.
[04:37] <fabrice_sp> ok (I didn't remember is Policy apply to development version). As soon as I've got a working package, I'll report the FTBFS to debian
[04:37] <fabrice_sp> thanks
[05:20] <diwic1> Hello, I would like a MOTU to perform a merge for Jaunty
[05:23] <stochastic> How should I format a copyright file if none of the headers have copyright attributions?
[05:24] <raof> stochastic: If its obvious that they're all under the same license as found in COPYING or whatever, then just as if they all had the same copyright header.
[05:24] <raof> stochastic: If it's not obvious what license they're under, then you get to play "poke upstream until Ubuntu can redistribute".
[05:25] <stochastic> raof, it's clear it's GPL, but no years are mentioned
[05:25] <fabrice_sp> diwic1, is there a bug in launchpad?
[05:26] <diwic1> fabrice_sp: #317254 and duplicates
[05:26] <fabrice_sp> bug #317254
[05:26] <raof> stochastic: Then, I guess, you don't have copyright years in debian/copyright.  But I'm not entirely sure.
[05:27] <_16aR_> Hello, any admin of revu there ?
[05:28] <dtchen> diwic1: it's enqueued for archive admin processing; please be patient.
[05:31] <stochastic> raof, I'm updating libphat0 (and it's dev counterpart) to the upstream version, and neither have anything in the copyright field of the debian/copyright file but lintian gives me warnings about this, should I just leave it without (it came from upstream that way)
[05:31] <diwic1> dtchen: Okay, thanks. Is there a way I can find status or know more about this "archive admin processing"?
[05:32] <raof> stochastic: If you don't have date information, I don't see what else you can do; you might want to get other opinions, though.  Also, libraries are a bit more complex; have you read the library packaging guide and done all the necessary ABI checks etc?
[05:32] <dtchen> diwic1: one of the archive admins will look at the bug in due time. i'm not an archive admin, so i don't have an ETA.
[05:33] <stochastic> raof, I'll take a look, I'm new to packaging, so I'm learning as I go...
[05:35] <raof> stochastic: You'll want to read at least the library packaging guide http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[05:36] <stochastic> raof, thanks
[05:41] <persia> Any REVU people about?  I'm troubleshooting the upload of hexdiff for _16aR_ (lp:dolanor).  The GPG key in use changed recently, and the package is repeatedly rejected, although the signature matches the key in LP.
[05:41] <persia> Anyone know how to force key resync?
[05:41] <coppro> wait 24 hours?
[05:41] <coppro> wait for a REVU admin to come along?
[05:43] <persia> coppro, I am a REVU admin.  I just haven't tried a resync since the LP integration.  Do you know that 24 hours fixes it?  I thought that might have changed with the LP integration.
[05:43] <coppro> oh.
[05:43] <coppro> in that case, no clue, since I do not have resync access. But IIRC, REVU resyncs automatically every 24 hours
[05:44] <persia> It certainly used to be that way, then it was stopped, and we did it manually roughly once a day.  I don't know the current state.
[05:44] <persia> nhandler, ?
[05:45] <dtchen> jpds: ^
[05:51] <hyperair> speaking of revus could someone review my package http://revu.ubuntuwire.com/details.py?package=sigx?
[05:53] <coppro> no, MOTUs don't review your packages; they just let them simmer and hope they get better :P
[05:54] <hyperair> T_T
[05:57] <hyperair> well i can't think of anything else i need to do, so i'd either like guidance or an advocate
[06:12] <jsmidt> Is there a website that keeps track of packages in debian and not Ubuntu?
[06:13] <jsmidt> And outdated packages in Ubuntu versus upstream?
[06:13] <dholbach> good morning
[06:14] <raof> jsmidt: We've got an Ubuntu external health thingy.
[06:15] <jsmidt> raof, found it, thanks
[06:19] <dholbach> was there anybody in the Italian "Getting Started" session yesterday and could post the log at https://wiki.ubuntu.com/MeetingLogs/devweek0901/GettingStartedIT ?
[06:25] <persia> jsmidt, You've found UEHS, or mdt, or both?
[06:27] <jsmidt> I found http://qa.ubuntuwire.com/ which seems to have everything
[06:27] <dholbach> hey warp10
[06:27] <dholbach> warp10: do you have the log of the Italian Getting Started session? :)
[06:28] <warp10> morning dholbach!
[06:28] <dholbach> warp10: could you add it to https://wiki.ubuntu.com/MeetingLogs/devweek0901/GettingStartedIT if you have it? :)
[06:28] <warp10> dholbach: I have about one hour and half of the whole log, my network had troubles in the remaining half hour
[06:28] <dholbach> warp10: no worries, I can ask quadrispro or gaspa once they turn up :)
[06:29] <dholbach> warp10: how did the session go on the Italian end?
[06:29] <warp10> dholbach: anyway, one of the attendant logged the whole sessione, he should be online soon
[06:29] <dholbach> warp10: super, thanks! :)
[06:30] <warp10> dholbach: very well, IMO. We had 4 or 5 people attending the session, and we covered the whole program: LP, GPG, setting up the tools, some basic information and a lot of questions! :)
[06:30] <dholbach> so we have a bunch of new Italian MOTUs soon? ;-)
[06:30] <warp10> dholbach: I really hope so! :D
[06:31] <dholbach> woohoo :)
[06:31]  * dholbach hugs warp10
[06:31]  * dholbach is really happy with how UDW is kicking off this time
[06:31]  * warp10 hugs back dholbach 
[06:31] <toresbe> OT: Are there any doxygen-literate people here? I'm faced with a problem that looks a lot like a bug and I don't know where to ask it.
[06:32] <warp10> dholbach: what about the other LoCo sessions? Lot of people attending everywhere?
[06:32] <jsmidt> Well everyone, thanks for the help.  I learned a lot today.
[06:32] <jsmidt> I was able to work on 10 bugs.  I've never been able to do that many.
[06:32] <dholbach> warp10: I think we had like 25 people in the German channel - what I liked very much was that they were all asking lots of questions in the sessions afterwards, so I'd say they found their way in (during the getting started session) quite easily
[06:33] <jsmidt> But I've tried a lot of new stuff so sorry in advance. :)
[06:33] <dholbach> jsmidt: Keep up the good work! :-)
[06:33] <jsmidt> Try not to  send to many angry emails.
[06:33] <jsmidt> Again, thanks for the help.
[06:33] <dholbach> toresbe: I used doxygen many years ago - I'm not sure I can help, but can take a look
[06:33] <toresbe> dholbach: thanks.
[06:34] <toresbe> I've been asked to fix up some PHP files (ugh) and I'm doxygenizing them now. For *one* of the files, a  completely unremarkable file, it is refusing to document the functions (but not the @file).
[06:35] <warp10> dholbach: oh, a *lot* of people! well, great! I hope we will keep on with these MOTU-Loco activities. The italian development team will be happy to partecipate
[06:35] <dholbach> toresbe: do you have that file, your Doxyfile and the log somewhere?
[06:35] <dholbach> warp10: that's exactly what I wanted to hear! :)
[06:35] <toresbe> dholbach: The log is uneventful; it parses the file no problem.
[06:35] <warp10> :D
[06:35] <toresbe> http://gunkies.org/stuff/problematic_php.txt
[06:35] <toresbe> that's the PHP file.
[06:35] <dholbach> warp10: let's try to plan a developer-loco-something day in a few weeks
[06:37] <toresbe> dholbach: http://gunkies.org/stuff/problematic_php_doxy.txt
[06:38] <toresbe> dholbach: Oops, ignore the colourful comment at the top of the code, please. :)
[06:38] <warp10> dholbach: cool! Feel free to ping me if you need help on the italian side :)
[06:39] <dholbach> warp10: super! :)
[06:40] <_ruben> ok .. this is weird .. im trying to backport bind 9.5 to hardy .. the ./configure command fails when run by pbuilder, but the same ./configure command runs just fine when run in the shell that i got via a pbuilder hook .. guess next step would be to see how debian/rules would go about things
[06:40] <dholbach> toresbe: does it document other files in the directory? does it stop somewhere? is there NO output at all about that file?
[06:42] <toresbe> dholbach: It documents other files no problem. It runs through the entire thing. The file is documented, but the *functions* are not.
[06:42] <toresbe> dholbach: subsequent @warnings in the same file *are* included; so it doesn't stop parsing. It just doesn't see @fns for *that* file.
[06:45] <dholbach> toresbe: very weird... I'm sorry I'm not of much help - it's been ages since I used it.
[06:45] <dholbach> toresbe: no idea
[06:46] <toresbe> dholbach: It's driving me crazy, documenting this code is something that I was supposed to be done with yesterday.
[06:47] <dholbach> toresbe: do the doxygen folks have an IRC channel?
[06:47] <toresbe> dholbach: Nope. :(
[06:47] <toresbe> That's why I'm asking in random channels wherein I expect to find clever people :)
[06:47] <dholbach> toresbe: I'd try there mailing list then
[06:48] <toresbe> dholbach: Sigh, I haven't got many good experiences with those.
[06:48] <_ruben> hmm .. even debian/rules build seems to work just fine .. must be some odd $ENV thingie messing stuff around .. oh well .. lets wait for the results first
[07:19] <persia> toresbe, Check your autotools configuration.
[07:39] <toresbe> persia: How could that change the behavior of an already-compiled program?
[07:40] <persia> toresbe, It oughtn't: it's just one of the places I tend to look when ./configure doesn't do what I'm expecting.
[07:41] <persia> Since ./configure is often run at package-time or build-time, I'm probably confused.
[08:18] <didrocks> Hi everyone
[08:19] <didrocks> I try to use start-stop-daemon in an init script, with -m option (to create the pidfile), but it does not write the right pid. I think the process is forking as soon as it starts (cf http://paste.ubuntu.com/107252/)
[08:19] <didrocks> consequently, my init script fails :/
[08:24] <savvas> where can I find documentation about .update-notifier files, the ones that go in /var/lib/update-notifier/user.d/ ?
[08:24] <didrocks> I can pgrep to erase the wrong pid, but well... I would prefer another solution
[08:24] <stefanlsd> didrocks: does the program not create its own PID?
[08:25] <didrocks> stefanlsd: unfortunately not. That's why I use the -m option
[08:25] <savvas> didrocks: is this about an init script/daemon?
[08:25] <stefanlsd> didrocks: yeah, it prob forks after starting. have u tried the -b option
[08:26] <didrocks> savvas: yes
[08:26] <didrocks> stefanlsd: not sure, let me check the manpage
[08:26] <didrocks> stefanlsd: yes, I used the long form. And same pid retrieved
[08:28] <stefanlsd> didrocks: mm. yeah. -m -b should hopefully do it. i can see its not thou.  -v help u anything
[08:30] <didrocks> stefanlsd: unfortunatly yeah, it seems that there is no solution with start-stop-daemon option. That's why I supposed to use pgrep to create it in the init script. Does this make sense?
[08:31] <stefanlsd> didrocks: yeah. not sure why start-stop-daemon isnt doing it properly, maybe we could investigate that more, but pgrepping and writing the PID and telling start-stop-daemon the PID file should be ok
[08:33] <didrocks> stefanlsd: ok, I will try to add more options (and to be in contact with upstream to see if he can implement it). If not possible, I will pgrep though :/
[08:33] <didrocks> thanks :)
[08:33] <stefanlsd> didrocks: suuure. good luck :)
[08:33] <savvas> didrocks: you're trying to "daemonize" a bash script, right?
[08:34] <didrocks> savvas: not a bash script, it's a C program
[08:34] <toresbe> dholbach: I found the problem, FWIW.
[08:34] <savvas> didrocks: I have something here I use for a bash, maybe it'll work for you: http://bazaar.launchpad.net/~timekpr-maintainers/timekpr/trunk/annotate/head%3A/debian/timekpr.init
[08:35] <didrocks> savvas: thanks. I will have a look at it :)
[08:36] <savvas> I use -m -b and --startas (no idea why, but it made it work) :P
[08:36] <didrocks> savvas: why --test and then, execute it. Is it mandatory?
[08:38] <didrocks> savvas: ok, I see it with the man page
[08:39] <didrocks> thanks, will give it a try
[08:39] <savvas> didrocks: --test tests if the file is present
[08:39] <savvas> there was an example init script somewhere in /etc/ I think, but I can't find it :\
[08:39] <didrocks> savvas: no pb, I will work from your example and see if I can use it
[08:40] <savvas> ok great :)
[08:41] <dholbach> toresbe: great - what was it?
[08:44] <toresbe> dholbach: I had functions with the same name in previously-interpreted files. All info was added to those files, and not to the file the function actually was in.
[08:44] <dholbach> ahhhhhh
[08:44] <dholbach> toresbe: that was hard to spot
[08:44] <dholbach> maybe file a bug report at doxygen? would be nice to have a warning for cases like that :)
[08:45] <toresbe> I'll do so
[08:46] <dholbach> super
[09:09] <dholbach> gaspa: do you still have the log of the Italian Getting Started session? if you do, could you please post it here:  https://wiki.ubuntu.com/MeetingLogs/devweek0901/GettingStartedIT  ?
[09:10] <gaspa> dholbach: i was just waiting for them, in order to put on the page.
[09:11] <dholbach> gaspa: great, thanks :)
[09:17] <huats> morning !
[09:31] <gaspa> dholbach: done. should I remove all time references, login/logout notifications and so on?
[09:31] <dholbach> gaspa: no, it's fine as it is
[09:31] <dholbach> thanks a bunch
[09:31] <gaspa> ;)
[09:32] <gaspa> it was amazing
[09:32] <dholbach> it was
[09:32] <dholbach> great work everybody :)
[09:32] <gaspa> and now I need an oculist, after an hour of writing without breaks... :P
[10:02] <schmiedc> oin #ubuntu-at
[10:13] <al-maisan> Koon: I am trying to package the ActiveMQ message broker which is Java software .. what is a good existing Java software package to look at?
[10:15] <Koon> al-maisan: I might be biased :)
[10:15] <al-maisan> no problem :)
[10:16] <Koon> al-maisan: I like to think tomcat6 was packaged correctly, but others might think otherwise.
[10:16] <al-maisan> Thanks!
[10:16] <Koon> al-maisan: ActiveMQ is a library rather than a server, right ?
[10:16] <al-maisan> I am a beginner and need an example to look at.
[10:16] <al-maisan> ActiveMQ is a server actually
[10:17] <al-maisan> It is a message broker
[10:17] <al-maisan> a JMS implementation
[10:17] <Koon> al-maisan: it runs standalone ? It should be started at the end of the package installation ?
[10:17] <al-maisan> Koon: yes, ideally.
[10:18] <Koon> al-maisan: then I'd recommend looking at tomcat6, yes. Libraries are easier, and the commons-* are good examples for that
[10:18] <al-maisan> Koon: good point, very much appreciated :)
[10:18] <Koon> al-maisan: also you might find #ubuntu-java helpful.
[10:18] <al-maisan> ah, OK.
[10:18] <directhex> pfft, java
[10:18] <directhex> ;)
[10:18] <al-maisan> didn't even know such a channel existed :)
[10:18] <Koon> directhex: everyone has a cross to carry :)
[10:19] <Koon> 'one cross each'
[10:19]  * al-maisan is not a big Java fan but that specific piece of software was written in Java
[10:19] <directhex> carry cross once, get nailed anywhere?
[10:19] <al-maisan> :P
[10:26] <slytherin> Koon: Welcome back. :-)
[10:27] <Koon> slytherin: heh thx
[10:42] <jmehdi> Could someone review my package: http://revu.ubuntuwire.com/details.py?package=webstrict, I've added a debian/watch file as required
[10:50] <_ruben> hm .. when building a package using pbuilder, how does one ensure the resulting .deb is signed with my key ?
[10:56] <maxb> _ruben: You mean .changes, right? .debs are never signed directly
[10:56] <_ruben> maxb: then what does apt-get check when downloading the debs from a mirror?
[10:57] <maxb> Checksums for the .debs are listed in the Packages file.
[10:57] <maxb> Checksums for the Packages file are listed in the Release file
[10:57] <maxb> The Release file is signed
[10:58] <_ruben> ah .. that should be enough to get me going for a bit .. thanks
[10:58] <maxb> _ruben: the .changes file (the upload control file) contains checksums for the .debs, and the .changes file is signed by the uploader to authenticate themselves to the archive they are uploading to
[10:59] <dholbach> ScottK: you were right about the sponsoring entries in the HoF (uploads) - thanks again
[11:00] <pochu> morning dholbach
[11:00] <pochu> (or should I say evening?) ;)
[11:00] <dholbach> hiya pochu
[11:00] <pochu> dholbach: I uploaded the logs right after you left
[11:00] <dholbach> no :)
[11:00] <dholbach> pochu: thanks a lot
[11:00] <pochu> yw
[11:00] <_ruben> maxb: ah .. so the .changes files would be signed by uploader, and the Release file by the repository ('s maintainer's special key)
[11:01] <maxb> In practice, usually the repository's automatic signing key, rather than any person-associated key, but yes
[11:01] <_ruben> maxb: that's what i realised during typing, hence the odd sentence ;)
[11:02] <_ruben> thanks .. time to re-do some stuff properly now :)
[11:03] <maxb> Incidentally, you don't have to sign .changes and source packages at time of build. You can just run "debsign" on them later (e.g. after you've tested them - or, even, on a different host to where you build them, if your key can't/shouldn't be on the build host)
[11:18] <WalterMundt> I'm looking at Twisted right now; there's been a new upstream release that's apparently not packaged yet in the archives.  I'm very new to this, but given the state of the debian release/etc, would it be helpful to try and update the packaging in Ubuntu?  In what form/where would I send the work when it's done, given that (old version of) the package is currently coming unmodified from Debian?
[11:18] <Laney> WalterMundt: doko_ maintains it, you should talk to him
[11:19] <WalterMundt> okay, good plan; I don't want to duplicate effort
[11:20] <WalterMundt> (more generally, I wonder how much interest the various Debian maintainers have in running updates through Ubuntu in the interim while the Debian release process does its thing.)
[11:20] <Laney> Debian has experimental available for use
[11:21] <WalterMundt> hmm, true
[11:38] <stochastic> how can I get at the config.log file from a pbuilder environment?
[11:38] <azeem> stochastic: you probably need to suspend it and chroot into it or something
[11:39] <azeem> I don't think you can get to it after the build
[11:39] <Laney> There's a hook you can set up to remain in the environment if a build fails
[11:39] <Laney> I don't have it, though
[11:39] <azeem> maybe CDBS should cat config.log if configure fails
[11:45] <savvas> Does anyone know where can I find documentation about .update-notifier files, the ones that go in /var/lib/update-notifier/user.d/ ?
[11:45] <maxb> There is some doc in the update-notifier source package, at least.
[11:54] <WalterMundt> stochastic: https://wiki.ubuntu.com/PbuilderHowto mentions the "keeping shell in pbuilder after fail" hook thing btw
[11:54] <WalterMundt> Laney: e-mailed doko_; may be back later depending on response
[11:54] <Laney> excellent, good luck
[11:56] <savvas> hm...
[11:56] <savvas> I found some in kubuntu wiki https://wiki.kubuntu.org/InteractiveUpgradeHooks
[12:06] <nhandler> persia: Did you need somethign?
[12:06] <nhandler> s/somethign/something/
[12:26] <persia> nhandler, _16ar_ changed the GPG key in LP recently, and it differs from the one in the LP database.  I don't know the command to run on spooky to fix this.  Do you?
[12:28] <persia> Err, ...differs from the one in the REVU database ...
[12:33] <nhandler> persia: Sorry, I don't. I don't even have access to spooky yet
[12:34] <directhex> https://launchpad.net/ubuntu/jaunty/+source/kde4bindings/4:4.1.96-0ubuntu1/+files/kde4bindings_4.1.96-0ubuntu1.dsc
[12:34] <directhex> bah
[12:34] <persia> nhandler, You've sent a request to UWSA?
[12:35] <persia> nhandler, Also, become a REVU Admin or REVU Hacker at your option: you don't really need to be either to be REVU Coordinator, as long as you get those of us who do have those roles (and Reviewer and Contributor) doing stuff.
[13:21] <directhex> http://primates.ximian.com/~miguel/pictures/moon-obama.png
[13:21] <directhex> bah
[13:21] <directhex> shameless plug: http://ubuntuforums.org/showthread.php?p=6584115
[13:25] <MaduserTr> How do I disable the executable flag in a image which executable in upstream?
[13:28] <liw> MaduserTr, do you mean that the .jpg (or whatever format it is) ends up with execute permissions in the .deb? normally debhelper normalizes permissions, but if not, you can add a command to debian/rules to change the permissions yourself
[13:31] <MaduserTr> liw, Yes this I mean. I use cdbs on a python program (wine-doors). Can I hook in the build to do so?
[13:32] <jpds> persia: Have you relogged into REVU with the new key on LP? That's how keys get synced in.
[13:32] <hyperair> MaduserTr: install/binary-package-name::
[13:32] <hyperair> MaduserTr: chmod 0644 debian/<tmp or binary-package-name, depending on whether you have more than one package or not>/path/to/jpg
[13:32] <persia> jpds, the user did relogin, but it didn't resync.  I had them log out and log in again, and forced the rejected .changes back into /srv/uploads
[13:33] <persia> The rejected .changes was signed by the key shown as the right key on LP.
[13:33] <jpds> persia: Oh, did it work after that?
[13:33] <persia> No.
[13:33] <MaduserTr> hyperair, thanks I will try to get it
[13:33] <hyperair> MaduserTr: if you've got cdbs installed on your comp, read the cdbs doc here: file:///usr/share/doc/cdbs/cdbs-doc.html
[13:33] <persia> That's why I'm asking for guidance: the last docs I have on being a REVU admin are out of date, and so I don't know how to fix this.
[13:35] <jpds> Hmm, no idea either.
[13:35] <mok0> persia, you have docs??
[13:35] <mok0> persia: I'd like to see those, even though they are out-of-date
[13:35] <persia> mok0, Yep.  sistpoty sent some out to ubuntu-motu about a year ago.
[13:36] <mok0> persia: I'll search the archive then
[13:37] <persia> mok0, March 2008
[13:37] <mok0> persia: thx
[13:38] <mok0> found it
[13:39] <mok0> shoudn't we have that on the wiki?
[13:39] <persia> Well, no.  We should probably have a section on the wiki that's accurate.
[13:39] <persia> At least I'd find it helpful, but I think we need help from REVU Hackers to do it.
[13:39] <mok0> persia: err yes, that's what I mean :-)
[13:40] <persia> In that case, Yes :)
[13:41]  * hyperair wonders if anybody is willing to revu some packages
[13:42] <mok0> sorry hyperair, trying to get some work done...
[13:42] <hyperair> okay
[13:42] <hyperair> no prob
[13:42] <hyperair> i'll wait another day =p
[13:43] <mok0> I am going early to watch the inauguration of Obama :-)
[13:44] <hyperair> =O
[13:44] <mok0> in 75 minutes
[13:49] <hyperair> =O
[13:50] <hyperair> well before you go, do you know what's required to make a package that links fine with libxul-dev to link fine with xulrunner-1.9-dev? it uses gtkmozembed
[13:50] <hyperair> -R works, but using an rpath is forbidden it seems
[13:51] <hyperair> and using the XPCOM glue causes ld to throw up a hissy fit about undefined references
[13:51] <slytherin> hyperair: I guess you will need to patch makefile.
[13:52] <hyperair> slytherin: i've done lots. patch Makefile.am, gecko.m4, among other things
[13:52] <persia> hyperair, Have you asked the Mozilla team?
[13:52] <hyperair> slytherin: and configure.ac
[13:52] <hyperair> eh no?
[13:52] <hyperair> where can i contact them?
[13:52] <MaduserTr> hyperair, liw, thanks got it
[13:53] <liw> MaduserTr, you're welcome
[13:53] <hyperair> MaduserTr: you're welcome
[13:53] <liw> MaduserTr, we thank you for choosing #ubuntu-motu for your development questions and hope that you will choose us again :)
[13:53] <liw> (do I fly too much?)
[13:54] <slytherin> hyperair: https://edge.launchpad.net/~mozillateam
[13:54] <MaduserTr> :)
[13:54] <james_w> hyperair: #ubuntu-mozillateam
[13:54] <schmiedc> liw: maybe :P
[13:55] <schmiedc> otherwise we do/get the same good service as we should :)
[13:55] <hyperair> james_w, slytherin: thanks
[13:56] <shankhs> How can I download the source code of geany http://bazaar.launchpad.net/~vcs-imports/geany/trunk/changes contains a lot of files which gonna take a lot of time to download,moreover I dont know which files to download which not.I am a newbie in development.
[13:56] <shankhs> Please help
[13:56] <Laney> shankhs: bzr branch lp:geany
[13:57] <shankhs> Laney: thats not working giving some erroe like:bzr: ERROR: socket.error: (111, 'Connection refused')  and asking to file a bug report
[13:57] <Laney> maybe something's wrong with LP
[13:57] <Laney> You can get it from geany's site too
[13:57] <hyperair> shankhs: are you behind some firewall of some sort?
[13:57] <shankhs> I am behind a proxy which needs authetincation
[13:58] <Laney> aha
[13:58] <shankhs> what should I do?
[13:58] <maxb> Does it not need to be lp:~vcs-imports/geany/trunk ?
[13:58] <Laney> maxb: I copied it from LP
[13:58] <mok0> Laney: "bzr branch lp:geany" ... that's the coolest reply I've seen in a while :-)
[13:58] <Laney> \o/
[13:59] <shankhs> maxb: ya its that /geany/trunk
[13:59] <shankhs> then how to make "bzr branch lp:geany work?
[14:00] <Laney> look into how to use bzr behind a proxy
[14:00] <james_w> python is broken behind proxies
[14:00] <mok0> bzr branch lp:geany/trunk
[14:00] <james_w> use the full url instead
[14:01] <james_w> "bzr branch bzr+ssh://youruser@bazaar.launchpad.net/~vcs-imports/geany/trunk"
[14:02] <mok0> proxies... an invention of nazi sysadms
[14:02] <shankhs> mok0: I disagree
[14:03] <shankhs> btw is there any security concerns with bazaar?
[14:03] <james_w> like what?
[14:04] <mok0> I guess proxies are needed to protect machines running Microsoft Windows...
[14:04] <liw> shankhs, not in particular: every program that accesses data from the network is always a security concern, if you're paranoid enough, but bzr doesn't do anything particularly worrying
[14:04] <shankhs> I am repeatedly getting bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[14:05] <shankhs> liw: I got it
[14:05] <hyperair> shankhs: try using tsocks
[14:05] <shankhs> hyperair: and now what is that tsocks???
[14:05] <james_w> shankhs: can you "ssh youruser@bazaar.launchpad.net"?
[14:06] <mok0> james_w: no one can
[14:06] <hyperair> shankhs: it's a wrapper, using LD_PRELOAD or something to wrap all outbound connections through a SOCKS proxy
[14:06] <james_w> mok0: sure you can
[14:07] <shankhs> james_w: no its saying: Permission denied (publickey).
[14:07] <mok0> james_w: well I don't get a connection
[14:07] <james_w> it doesn't give you a shell, but it's a connectivity/key etc. test
[14:07] <james_w> shankhs: ah, have you registered an ssh key with launchpad?
[14:07] <shankhs> :( no
[14:08] <shankhs> how to do that?
[14:08] <mok0> that's a _public_ key
[14:08] <mok0> shankhs: do it from your LP home page
[14:09] <james_w> shankhs: or use "bzr branch http://bazaar.launchpad.net/~vcs-imports/geany/trunk"
[14:10] <shankhs> james_w: I wonder where is the ssh key in my profile...
[14:11] <shankhs> james_w: where is the downloaded file saved???
[14:12] <james_w> shankhs: click "change details" in the top right, the "ssh keys" at the top
[14:12] <james_w> that command will create a directory called "trunk"
[14:16] <shankhs> james_w: thanx a lot
[14:16] <shankhs> thanx everybody
[14:33] <MaduserTr> I have uploaded a new Version of wine-doors to revu (http://revu.ubuntuwire.com/details.py?package=wine-doors) maybe some can have a look
[14:35] <lidaobing> help review ibus-pinyin: http://revu.ubuntuwire.com/details.py?upid=4583
[14:36] <lidaobing> thanks
[14:49] <ScottK> dholbach: So it's fixed now (HoF sponsoring uploads)?
[15:12] <_ruben> what am i missing here .. i signed my own repo's Release file with a dedicated gpg key, i imported its public key using apt-key, but apt-get still doesnt like my repo :(
[15:16] <maxb> _ruben: is it a publicly accessible repo?
[15:16] <_ruben> maxb: no
[15:17] <maxb> Then you'll need to provide as much information as you can manage here, if people are to be able to help
[15:18] <_ruben> lets see if i can increase the verbosity or smth
[15:19] <maxb> Or, you could set up a publicly accessible repo, get that working, and then apply the lessons learnt to your private one
[15:19] <_ruben> lets start by reading the actual error :P ... Unknown error executing gpgv
[15:19] <_ruben> W: You may want to run apt-get update to correct these problems
[15:19] <_ruben> gotta love "unknown errors"
[15:19] <maxb> !
[15:24] <_ruben> doh .. didnt sign my release file properly .. *slaps forehead*
[15:36] <dholbach> ScottK: yep
[15:36] <ScottK> dholbach: Great.  Now if I get on the list it'll be honest.
[15:36] <dholbach> hehe
[15:40] <superm1> \
[15:43] <dholbach> Ubuntu Developer Week - Day 2 just about to start in 17m in #ubuntu-classroom :)
[15:44] <jpds> dholbach: Hmm, do you want the mute off or should I keep it there?
[15:45] <dholbach> jpds: not necessary - it went alright yesterday without it
[15:45] <jpds> Remove it then?
[15:45] <dholbach> yeah
[15:46] <jpds> OK; done.
[15:46] <dholbach> gracias
[15:51] <Ape3000> Does MOTUs also manage the main and restricted repos?
[15:51] <rhpot1991> cody-somerville: ping, just checking to make sure my SRU doesn't get lost
[15:51] <cody-somerville> rhpot1991, link?
[15:52] <rhpot1991> cody-somerville: https://bugs.launchpad.net/ubuntu/+source/mythexport/+bug/297019
[15:53] <cody-somerville> rhpot1991, ah, right
[15:54] <rhpot1991> cody-somerville: its a monstrosity I know :)  Just hoping to get it out of the way so I can continue working on the next version and push that out
[15:56] <rhpot1991> cody-somerville: the changes are all very minor, I can discuss exactly what the code changes were for each if it helps
[15:56] <Riddell> superm1: what's happening with bug 302104 ?
[15:56] <superm1> Riddell, nuke the upload for it, there is a new SRU in place for it that's waiting for a motu-sru ACK
[15:57] <rhpot1991> Riddell: I was told to move this into bug 297019
[15:57] <rhpot1991> so I moved the debdiff there (might be easier to just grab from bzr), and tried to update everything accordingly
[15:57] <superm1> Riddell, so once that has an ack i'll reupload for rhpot1991
[15:57] <Riddell> superm1: ok, I'll close that bug then
[15:57] <superm1> Riddell, thanks
[15:59] <cody-somerville> rhpot1991, Acked
[15:59] <rhpot1991> thanks cody-somerville
[15:59] <pochu> Ape3000: no, that's done by core-devs
[15:59] <cody-somerville> rhpot1991, There are some extra conditions on your SRU. Please ensure you adhere to them.
[16:04] <rhpot1991> ok will do cody-somerville
[16:08] <cody-somerville> rhpot1991, please ensure that you have the appropriate bug number in your changelog too
[16:09] <rhpot1991> cody-somerville: ok I'll check on that right now
[16:09] <rhpot1991> I think it has the old SRU one
[16:24] <jsmidt> Which command will merge Ubuntu and Debian changelogs?
[16:26]  * pochu doesn't know of any, but would be interested if there's one
[16:30] <_MMA_> Is new package freeze Feb 19th?
[16:34] <quadrispro> anyone on REVU? -> http://revu.ubuntuwire.com/details.py?package=uck
[16:40] <RainCT> quadrispro: advocated
[16:41] <quadrispro> RainCT: ohh! thank you! and... ehm... *cough* http://revu.ubuntuwire.com/details.py?package=w-scan
[16:41] <quadrispro> :D
[16:41] <Laney> heh
[16:44] <jmehdi> Could someone review my package: http://revu.ubuntuwire.com/details.py?package=webstrict, I've added a debian/watch file as required
[16:44] <RainCT> quadrispro: did you say something I only heard you cough *g*
[16:46] <quadrispro> RainCT: sorry for bothering you again :)
[16:46] <bddebian> Heya gagn
[16:46] <bddebian> Err gang even
[17:21] <ia> if i'm going to upload some package at ppa, is it necessary that package name contains "~ppa" string?
[17:21] <jpds> ia: If you want, ~ppaN would be better.
[17:23]  * maxb really needs to write up a long bug discussing why ~ppaN is highly suboptimal
[17:25] <jpds> maxb: I think it's on help.lp.net/PPA .
[17:25] <maxb> yeah. That section really needs an overhaul
[17:26] <maxb> It discusses well what constraints a PPA version should meet, but then proposes a scheme (~ppaN) which doesn't meet them as well as it could, at all
[17:30] <ScottK> help.lp.net/PPA is still broken in regards to it's revision numbering recommendations.
[17:30] <ScottK> It could also stand to know the difference between a version and a revision.
[17:43] <asomething> any motu-swat or sru around? I've got an intrepid security update that's been waiting for review for awhile. bug 291531
[17:44] <jdstrand> asomething: hi! thanks for your patch.
[17:44] <jdstrand> asomething: I am going to mark the bug In Progress, as per SecurityUpdateProcedures
[17:45] <jdstrand> asomething: we have scripts to help us find community contributions like yours, but this one slipped by because it wasn't marked in progress
[17:46] <jdstrand> asomething: a member of our team should be able to process the upload within the next few days, now that we know about it
[17:47] <asomething> jdstrand: ya, I also just noticed that since it's targeted at intrepid and fixed in jaunty it doesn't show up in a lot of bug lists
[17:47] <asomething> jdstrand: thanks for taking a look
[17:47] <jdstrand> asomething: np. thanks for your help on this! :)
[18:37] <tgm4883> can other keyring packages be included in universe, or is that limited to debian-keyring and ubuntu-keyring
[18:38] <maxb> Would it make sense to include others?
[18:38] <slytherin> tgm4883: what keyrings do you want to include?
[18:39] <tgm4883> mythbuntu-keyring
[18:40] <tgm4883> slytherin, it would be a the key for the weekly-builds repo, which will be the PPA now that it is signed
[18:42] <maxb> Couldn't the keyring just go in the PPA? Users would accept an unauthenticated warning once only, that way?
[18:42] <slytherin> tgm4883: in my opinion it doesn't make sense to include these keyrings in universe since they are not being used by officialarchives.
[18:42] <tgm4883> maxb, it could, but then it couldn't be included on the ISO
[18:45] <fabrice_sp> Hi! Any MOTU here to review DVDStyler, a dvd authoring tool (http://revu.ubuntuwire.com/details.py?package=dvdstyler). It has already been advocate dby mok0.
[18:46] <slytherin> tgm4883: why do you want to include keyrings used by PPA on CD?
[18:46] <maxb> It seems slightly peculiar to include a weekly-build keyring on CD
[18:46] <maxb> (to me)
[18:47] <ScottK> tgm4883: I don't think we're going to allow PPA keyrings on a CD.
[18:48] <tgm4883> slytherin, maxb well the reason for the weekly builds is so people will have up to date builds of the -fixes branch (not trunk).  Using the PPA (or our own repo, as we have done in the past) is easier that trying to get a backport for it every week
[18:48] <tgm4883> We can do it via apturl and in the PPA, just thought i'd check first
[18:51] <maxb> If regular updates are so important that most users should be using them, then perhaps the answer is to try to make official backports easier?
[18:52] <tgm4883> I suppose that would work, but would then in effect be making -backports a rolling repo
[18:52] <tgm4883> which I thought was frowned upon anyway
[18:53] <ScottK> tgm4883: We've reverted stuff before that took updates from a PPA due to security concerns.   Just have them add the PPA to their sources.list and be done with it.
[18:53] <tgm4883> ScottK, will do
[18:58] <iefremov> Hi All, reviewers needed for newly uploaded package ugene (http://revu.ubuntuwire.com/details.py?package=ugene). Ugene is a quite complex and interesting bioinformatics package based on Qt.
[19:00] <ScottK> iefremov: If you see mok0 around, that sound like something he'd be interested in.
[19:01] <iefremov> ScottK: OK, thanks
[19:17] <maxb> Where could I go to find a pbuilder expert? Specifically, to understand why the pdebuild manpage says about --use-pdebuild-internal: "This option will not protect the working directory and its parent directories from the build scripts."
[19:32] <hyperair> maxb: it bind mounts your source directory into the chroot, then performs operation there
[19:32] <hyperair> maxb: meaning that the build is done using the source directory itself, not a copy of it
[19:33] <maxb> Right... I get that the build can affect stuff within the bind mounted tree... it's the reference to the parent directories that I don't understand
[19:33] <hyperair> maxb: it probably bind-mounts your parent directory
[19:33] <hyperair> maxb: not the source directory
[19:34] <hyperair> maxb: so if i have a directory called build-area/ and inside build-area a folder called source-1.2.3, then it bind-mounts build-area
[19:34] <hyperair> maxb: so if you've got dsc files like.. source_1.2.3-0ubuntu1.dsc or something, it'll be overridden
[19:35] <hyperair> maxb: in the parent directory of source-1.2.3 that is
[19:35] <maxb> hmm. /me will experiment, but even so, parent *directories* would then be an error in the manpage?
[19:35] <hyperair> oh
[19:35] <hyperair> ._.
[19:35] <hyperair> i have no idea
[19:35] <hyperair> this is just my interpretation
[19:35] <hyperair> i could be wrong
[19:36] <hyperair> what you could try is run the pdebuild-internal thing and before it's done, run mount
[19:36] <hyperair> and see which part is bind-mounted
[19:36] <maxb> I see, you are right about the parent directory being bound
[19:37] <hyperair> ah
[19:37] <maxb> I reckon the manpage shoud s/directories/directory/
[19:37] <hyperair> yep
[19:37] <hyperair> file a bug =p
[19:39] <maxb> yup
[19:41] <_16aR_> Hello
[19:42] <RainCT> OT, can someone recommend me a cheap bluetooth remote for the laptop? (to control a slideshow and the like; if it can also move the mouse and stuff even better)
[19:48] <_16aR_> any motu revu admin ?
[19:48] <jpds> _16aR_: Hi.
[19:48] <RainCT> _16aR_: yes?
[19:48] <_16aR_> Hello jpds
[19:48] <_16aR_> I got a problem yesterday with an uploaded package
[19:48] <_16aR_> with persia with thought that it was the gpg keylist not updated
[19:49] <_16aR_> I uploaded ok with dput, but then, it didn't appear on the revu frontpage
[19:49] <RainCT> _16aR_: did you login on REVU before uploading the package?
[19:49] <_16aR_> I updated my gpg key yesterday, so it might be that
[19:50] <_16aR_> the first time, no
[19:50] <_16aR_> the second time, i dput -f, and I was connected to revu
[19:50] <_16aR_> for the first time, I'm nearly sure I wasn't connected
[19:52] <RainCT> _16aR_: which package is it?
[19:52] <_16aR_> sorry :)
[19:52] <_16aR_> lp: dolanor, package : hexdiff
[19:54] <RainCT> _16aR_: It's up now. Not sure what the problem was, but I've just told REVU to look at it again and it accepted it
[19:54] <_16aR_> ok, thanks a lot :
[19:55] <_16aR_> :)
[19:55] <RainCT> you're welcome
[20:08] <hyperair> RainCT: got time for a revu? =p
[20:15] <RainCT> hyperair: sorry, school work :(
[20:16] <hyperair> ah okay no prob
[20:16] <hyperair> i've got school work too =p
[20:18] <mrooney> have I botched something with my last upload? http://revu.ubuntuwire.com/details.py?package=wxbanker
[20:18] <mrooney> I am getting permission denied on viewing the files and the last upload says legal instead of debdiff
[20:19]  * jpds takes a look.
[20:19]  * mrooney waves at jpds
[20:19] <RainCT> mrooney: you can't create a debdiff between the last upload and the last upload :9
[20:20] <RainCT> * s/:*/:)
[20:20] <RainCT> ** s/:9/:)
[20:20] <mrooney> I didn't try to do anything really, all I did was update the package and run dput
[20:20] <jpds> mrooney: Hi. :)
[20:20] <hyperair> RainCT: yes you can =p you just get an empty file
[20:21] <mrooney> I feel like the permission thing happened to me the first time I did this,hmm
[20:21] <RainCT> hyperair: but with REVU you can't :P
[20:21] <jpds> mrooney: Everything works, we block off the .changes file so noone can upload the package anywhere else.
[20:21] <RainCT> mrooney: uhm.. it's working for me
[20:21] <mrooney> debian packaging / getting packages into Ubuntu seems to have an astronomical learning curve :)
[20:21] <hyperair> RainCT: point taken =p
[20:22] <hyperair> mrooney: not so much if you've got some programming background and have read the cdbs documentation, as well as the debian packaging guide and/or ubuntu packaging guide
[20:22] <hyperair> mrooney: it used to be steeper
[20:23] <jpds> mrooney: Say a MOTU uploads a package, all a person who had access to the .changes got it and the package, they would then be able to upload it to Ubuntu, just because it's signed by a MOTU's key.
[20:23] <jpds> s/all a/any/
[20:24] <mrooney> jpds: ahh I see, the diff is what I was looking for I think :)
[20:24] <jpds> mrooney: I can view the .diff and .diff.gz fine...
[20:24] <mrooney> jpds: yeah, I can as well
[20:25] <mrooney> I was thinking what I wanted was the .changes though, and was getting confused
[20:25] <jpds> Ah, I thought you were trying to get to them and were getting permission denied.
[20:33] <mrooney> So overall it looks fine, that's good
[20:33] <mrooney> is there any way to get it to not generate a pycompat, I hear I don't need it and it is wrong anyway.
[20:33] <mrooney> Other than nuking it before dput'ing
[20:40] <RainCT> woho, my website is working again
[20:40] <maxb> If a new package version Conflicts: and Replaces: something, shouldn't apt-get dist-upgrade remove the conflicted/replaced package in favour of upgrading to the new version, instead of the new version being kept back?
[20:43] <pochu> maxb: that only if something wants to install the other package, or if the installed package provides the new one
[20:43] <pochu> IIUC
[20:43] <maxb> hmm
[20:43] <pochu> otherwise, the other package replaces and conflicts with the current one, but why to replace it if nothing wants it? :)
[20:44] <maxb> I just did an intrepid -> jaunty upgrade and was left with intrepid's gstreamer-plugins-bad
[20:44] <maxb> because jaunty's plugins-bad conflicts with fluendo-mpegdemux
[20:45] <xnox> what is linda? was it retired in favor of lintian?
[20:45] <pochu> xnox: it was a lintian clone written in Python, but was abandoned
[20:45] <maxb> hmm, still kept back even with a Provides
[20:46] <pochu> maxb: that's weird
[20:46] <pochu> hmm
[20:46] <pochu> 21:44 <      maxb> because jaunty's plugins-bad conflicts with fluendo-mpegdemux
[20:46] <pochu> does it also have a replaces?
[20:46] <maxb> yes
[20:47] <pochu> dunno why
[20:47] <pochu> +then
[20:47] <maxb> Actually, the package doesn't really have a replaces, but I added one and it still didn't work
[20:50] <pochu> where did you add it?
[20:51] <maxb> right in apt's /var/lib/apt/lists/*, and then vaped apt's caches :-)
[20:51] <pochu> heh
[20:52] <pochu> so I guess `apt-cache show` shows the Replaces
[20:52] <maxb> oh well, bug 319369 filed, I'd hoped to suggest a fix, but nevermind
[20:52] <pochu> maxb: did you try with aptitude? :P
[20:52] <maxb> I like apt-get :-)
[20:52] <maxb> Call me a traditionalist
[21:07] <hyperair> maxb: hear hear
[21:08] <hyperair> maxb: aptitude has messed things up for me more than it's helped me
[21:08] <hyperair> anyway does anybody have some time to revu?
[21:10] <maxb> I'm not a MOTU, but I can see if I can catch anything so they don't have to, if you like
[21:12] <hyperair> thanks =p http://revu.ubuntuwire.com/details.py?package=sigx http://revu.ubuntuwire.com/details.py?package=vazaar http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[21:12] <hyperair> three packages - sigx, vazaar, bansheelyricsplugin
[21:13]  * hyperair needs to get some sleep before class begins
[21:23] <stochastic> Does any motu want to REVU my newest upload (I think everything is fixed now) http://revu.ubuntuwire.com/details.py?package=calf
[21:24] <xnox> pochu: thanks for info about linda. Sorry it took a while to respond I ran away =D to save my burning rice =D
[21:47] <jsmidt> What does ACKed mean?
[21:47] <jpds> jsmidt: Acknoledged.
[21:47]  * jpds sighs, dumb keyboard: acknowledged.
[21:50] <jsmidt> thanks jpds
[21:51] <ScottK> When he comes back someone should explain to hyperair that sleep is what class is for.
[22:33] <Laney> jsmidt: What is that debdiff for on the axel sync?
[22:34] <jsmidt> Laney, it is for the axel in debian unstable: http://ftp.debian.org/debian/pool/main/a/axel/axel_2.3-1.dsc
[22:35] <Laney> jsmidt: I know, I'm just curious as to why you'd attach a debdiff. Do you know how syncs work?
[22:35] <jsmidt> Laney, maybe not.  I thought this is how you do them.
[22:36] <Laney> jsmidt: No. We just copy the package from Debian.
[22:36] <Laney> !sync
[22:36] <Laney> ..
[22:36] <Laney> https://wiki.ubuntu.com/SyncRequestProcess
[22:37] <jsmidt> Laney, thanks I will read through this.
[22:37] <Laney> It's always a good idea to make sure you know what you're asking people to sponsor
[22:38] <Chris`> Laney: Busy? :)
[22:39] <Chris`> eww has the font changed over at revu?
[22:39] <Chris`> Anyway, Laney fancying reviewing something? http://revu.ubuntuwire.com/details.py?package=partitionmanager
[22:39] <Laney> give me a minute to shower
[22:39] <Chris`> Positive :)
[22:42] <xnox> can anyone point to an intersting python-app/module which has unittest. Want to see/learn how to package and run testsuite at build/install time.
[22:44] <mrooney> xnox: oh, that sounds cool, I'd be interested as well
[23:06] <Chris`> pochu: Thanks for the type notice, was that the only error?
[23:07] <Chris`> *typo
[23:08] <pochu> Chris`: no, I just looked into the description to see what it was about :)
[23:08] <pochu> and spotted it
[23:09] <Chris`> Ok thanks anyway then :)
[23:09] <pochu> let me do a review of the debian/ dir
[23:12] <pochu> http://revu.ubuntuwire.com/revu1-incoming/grdc-gnome-0901161833/grdc-gnome-0.3.0/debian/grdc-gnome.pod <- AWESOME
[23:12] <Chris`> *Blushes*
[23:12] <Chris`> I thought that it was incredibly short personally
[23:12] <pochu> I've always written manual pages directly with the .TH .SH blah \fB\-\-some\-option ... syntax :P
[23:13] <pochu> Chris`: it's fine :)
[23:13] <pochu> I need to learn that pod thing :)
[23:14] <Chris`> pochu: Yeah it's a hell of a lot easier than what groff looks like
[23:16] <pochu> Chris`: comment added. Looks pretty good :)
[23:17] <Chris`> pochu: Thanks a bunch, my best review so far
[23:18] <proppy> Chris`: typo in http://revu.ubuntuwire.com/revu1-incoming/grdc-gnome-0901161833/grdc-gnome-0.3.0/debian/grdc-gnome.pod :)
[23:18] <proppy> s/funcitons/functions
[23:18] <pochu> heh
[23:18] <Chris`> proppy: Thanks for the heads up
[23:19] <proppy> Chris`: yw :)
[23:19] <proppy> pochu: sry ;)
[23:21] <pochu> proppy: it was a perfect review before you spotted it :(
[23:21] <pochu> ;)
[23:21] <proppy> pochu: typo on http://revu.ubuntuwire.com/ !
[23:22] <proppy> s/Utnubu team/Ubuntu team/
[23:22]  * proppy in typo mode
[23:22] <ia> hello. for example, i made deb package with newer upstream's app version, than exist in ubuntu/debian's repos and would like that it has been included in universe/multiverse repo; so, i should to find sponsor for upload, or try to upload package in revu first?
[23:22] <Chris`> "Error '553 Could not create file.' during ftp transfer of grdc-gnome_0.3.0.orig.tar.gz"
[23:23] <pochu> proppy: not a REVU hacker/admin/whatever ;)
[23:23] <Laney> proppy: That's not a typo
[23:23] <pochu> ah, yeah
[23:23] <pochu> read it from right to left :)
[23:23] <proppy> oh sorry :)
[23:24] <Chris`> http://pastebin.com/m35302024
[23:24] <Chris`> Does anyone know how that error happened?
[23:25] <proppy> Chris`: strange I thought -f meaned overwrite
[23:25] <Chris`> Well strangely, http://revu.ubuntuwire.com/details.py?package=grdc-gnome has updated if you wanna double-check
[23:25] <Chris`> I got the error but it seems to have worked...
[23:27] <Chris`> I wasn't so sure about the copyright icon, I hope that I did that correctly
[23:27] <proppy> Chris`: grep 553 in https://wiki.kubuntu.org/MOTU/Packages/REVU
[23:27] <proppy> To solve this, just wait 5 minutes.  Processing of uploads is done every 5 min.
[23:28] <Chris`> proppy: I think that it's now worked, it looks like dput may have tried to upload twice =\
[23:30] <Chris`> It tried twice or something... http://paste.ubuntu.com/107520/
[23:31] <proppy> Chris`: maybe just wait 5min and try to dput again
[23:31] <Chris`> Ok successfully dputed now :D
[23:33] <Chris`> http://revu.ubuntuwire.com/details.py?package=grdc-gnome -- When you have the time
[23:34] <Laney> Chris`: I ran lintian -iI on the binary changes file, threw some stuff up
[23:35] <Chris`> Laney: Fancy sharing? :)
[23:35] <Laney> http://pastebin.com/f12cefaa9
[23:35] <Chris`> Thanks
[23:36] <Chris`> Ah... you have to be kidding me?
[23:37] <Chris`> How is there a quilt error if quilt isn't even in the build-deps?
[23:38] <Laney> Other than that, the only thing you might consider is using the machine readable copyright format, but that's optional
[23:38] <Chris`> Laney: Do you mean (C)?
[23:39] <Laney> Chris`: No, http://wiki.debian.org/Proposals/CopyrightFormat <- that
[23:41] <Chris`> Je ne le comprends pas...   What do you mean exactly?
[23:41] <mrooney> Would anyone mind giving a quick lookover of http://revu.ubuntuwire.com/details.py?package=wxbanker, I got a previous review and attempted to address the issues with a new upload