[00:03] <Syntux> can we use non-english characters in URLs, description or name in debian/control ?
[00:09] <DktrKranz> k0p, yes. advocates are resetted when pushing a new upload.
[00:09] <k0p> DktrKranz, xiii
[00:09] <k0p> DktrKranz, I don't know about that.
[00:10] <k0p> DktrKranz, so I need to talk with norsetto again. After that can you put the advocate again? sorry
[00:10] <DktrKranz> sure
[00:10] <DktrKranz> ping me when ready
[00:10] <k0p> DktrKranz, ok.
[00:11] <k0p> another question. do you test in intrepid right?
[00:11] <DktrKranz> i built in intrepid, yes
[00:11] <k0p> yeap.
[00:11] <k0p> And I test in hardy.
[00:12] <k0p> it works fine. But not with norsetto.
[00:12] <k0p> I don't discover what's happen
[00:13] <DktrKranz> k0p, I haven't tested it properly, just sure it installs and removes cleanly, are there issues with program itself?
[00:14] <k0p> well ... I don't know.
[00:14] <k0p> norsetto tell me that in hardy
[00:14] <k0p> nothing appears after run umit
[00:15] <k0p> DktrKranz, do you run umit?
[00:16] <DktrKranz> just a sec, I'll install it
[00:17] <k0p> ok :)
[00:17] <DktrKranz> done
[00:18] <DktrKranz> launched
[00:18] <k0p> yeap
[00:18] <DktrKranz> now launched with sudo to avoid warning message
[00:18] <k0p> DktrKranz, lot of people runs it in hardy and intrepid.
[00:19] <DktrKranz> me too
[00:19] <k0p> noones reports errors
[00:20] <DktrKranz> I did a couple of scans, no issues here
[00:20] <k0p> yeah
[00:20] <k0p> the only issue with norsetto was lauching
[00:20] <DktrKranz> launched from menus now
[00:20] <DktrKranz> it works.
[00:20] <k0p> yeap works.
[00:21] <DktrKranz> ha! missing su-to-root
[00:21] <DktrKranz> this needs fixing
[00:21] <k0p> DktrKranz, how I do that?
[00:22] <DktrKranz> I don't remember which is the common behaviour... let's see
[00:23] <DktrKranz> in GNOME, gksu is common
[00:23] <k0p> yeap.
[00:23] <k0p> but people tells to put su-to-root.
[00:24] <DktrKranz> IIRC, that's not the good one, though
[00:24] <DktrKranz> if you want to use su-to-root, you have to add menu in Depends field
[00:25] <k0p> I do it.
[00:25] <DktrKranz> ah... I got older version ;)
[00:28] <DktrKranz> k0p, it's quite late here, I think it's good to talk with norsetto to see issues he faced in Hardy
[00:28] <DktrKranz> and I'm moving to bed too :)
[00:28] <k0p> DktrKranz, ok.
[00:28] <k0p> i'll do the same
[00:28] <k0p> DktrKranz, thanks. I'll talk to advocate when it's ready ;)
[00:28] <k0p> good night ;)
[00:29] <k0p> thanks
[00:46] <k0p> someone could review my package? I already have a ack. http://revu.ubuntuwire.com/details.py?package=umit
[01:26] <NCommander> hola folks
[01:27] <Hobbsee> heya!
[01:37] <NCommander> hey Hobbsee
[01:37]  * NCommander just got a new part for his laptop to fix it
[01:37] <Hobbsee> \o/
[01:38] <RAOF> Woot
[01:48]  * NCommander double clicks RAOF randomly
[02:06] <eck> where is the debian standards located? e.g. if i wanted to actually read whatever the Standards-Version: 3.8.0 is, where would I look?
[02:07] <crimsun> debian-policy
[02:07] <eck> thanks
[02:07] <crimsun> sorry, that's the package name
[02:07] <crimsun> http://www.debian.org/doc/debian-policy/  is the URL
[02:30] <RAOF>  Oh.  It seems that upstream has put Xgl out of its misery.
[02:31] <RAOF> So now we get to work out whether _we_ want to remove it from Intrepid.
[02:34] <ogra> how did they do it ? did they finish it off finally ?
[02:35] <RAOF> git rm xgl/*
[02:35] <ogra> yay
[02:35] <RAOF> Well, kinda.
[02:36] <RAOF> There's a group of users who'll no longer be able to get Compiz if we drop Xgl.
[02:37] <ogra> unless nvidia reacts on their mails ;)
[02:37] <RAOF> And adds features to a driver that's been superceded by _three_ newer drivers?
[02:37] <RAOF> Colour me skeptical.
[02:38] <ogra> well, xgl broke tons and tons of ltsp setups ... and caused us major headdaces in the support channel ...
[02:38] <RAOF> Oh, yeah.  Xgl was _crap_ and full of unfixed bugs.
[02:39] <ogra> if admins thought they are cool and installed xgl ... and suddenly 200 VIA based thin clients dont work anymore
[02:39] <RAOF> I implemented a blacklist to prevent that from happening.  It didn't work?
[02:39] <ogra> (the admins indeed worked on the server directly with the nvidia onboard card :P )
[02:39] <RAOF> Oh.  Craziness.
[02:39] <ogra> not if your display is remote
[02:39] <RAOF> Right.
[02:40] <ogra> ltsp uses ssh -x user@server /etc/X11/Xsession
[02:40] <ogra> so if xgl starts as part of the session ... boom ...
[02:40] <ogra> your X is already up on the client before thats run
[02:41] <RAOF> Urgh.
[02:41] <ogra> and finding out that the admin simply didnt tell you he had xgl installed ... after a week of debugging ... well ...
[02:41] <ogra> :)
[02:42] <crimsun> TheMuso: norsetto's fixes have been in my branch since early june...
[02:42] <crimsun> TheMuso: (for pulseaudio)
[02:43] <ogra> crimsun, while i got you here, do you see any reason to keep libflashsupport in intrepid with flash 10 ?
[02:43] <TheMuso> crimsun: Ahj right, sorry I forgot about your branch.
[02:43] <ogra> i'd like to drop it asap
[02:44] <crimsun> ogra: I see no reason
[02:44] <ogra> great :)
[02:45] <RAOF> ogra: Was that re: Xgl?
[02:45] <ogra> RAOF, nope thats was just a question to the master of sounds :)
[02:45] <RAOF> Right.
[02:56] <ember> is something wrong with revu? i kinda uploaded a new package a while ago and it's not showing
[03:08] <ember> hmm i was sending to the old .de . anyone willing to review http://revu.ubuntuwire.com/details.py?package=hamster-applet
[03:44] <ffm|sh> what buildsystem should I use (I'm a deb newbie, and I'm making a new package, a _very_ small one)
[03:57] <TomJaeger> =In order to get a package into the archive, is it really a requirement that each source file contain that useless copyright junk?
[03:59] <crimsun> TomJaeger: not a hard requirement, no.  Of course, not following it means that you make the reviewers' and archive admins' lives more difficult.  And when you make their lives difficult, you make it less probable they'll accept it.
[03:59] <crimsun> TomJaeger: and no, that "useless copyright junk" is NOT "useless..junk".
[04:02] <TomJaeger> well, I don't really see an advantage over a single LICENSE file, but okay.  It'd just be a major pita for me to include it right now, rather than with the next upstream release.
[04:05] <crimsun> TomJaeger: whatever works for you, as long is it's easy for the archive admins to tick off.
[04:05] <crimsun> as long as*
[04:05] <crimsun> ("tick off" == verify appropriate licences)
[04:06] <TomJaeger> okay, I'll add a comment to the REVU page
[04:08] <foxbuntu> any one what to do when you need to divert a file when its already being diverted by another package?
[04:08] <TomJaeger> Btw, for the ISC license, would one reproduce the whole license in each header or would the "Permission to use..." part be enough?
[04:11] <crimsun> see what the bind9 source does.
[04:12] <TomJaeger> thanks, already checking
[04:13] <TomJaeger> They reproduce the whole license, so I'm going to do the same
[04:15] <crimsun> you'll never go wrong reproducing the entire licence(s)
[04:29] <TomJaeger> but I don't need to add a license to a glade file, right?
[04:31] <NCommander> yay, my laptop works again
[04:34] <TomJaeger> god, this is such a waste of time.  Now all my files contain the text "ISC DISCLAIMS ALL WARRANTIES".
[04:36] <NCommander> TomJaeger:?
[04:38] <TomJaeger> copied the license from the bind source because they already had the correct * formatting.  However, I'm not ISC and now I have to replace all occurrences of ISC with THE AUTHOR.
[04:38] <ion_> A sed oneliner.
[04:39] <TomJaeger> if you don't care that lines be less than 80 characters long
[04:40] <ion_> A quick vim macro, then.
[04:46] <Hobbsee> RAOF: in your gnome-do development, do you think it'd be possible to get the standard 'open' for a text document to open in something other than less?
[05:03] <TomJaeger> why does that every-source-file-must-have-a-license-header rule not apply to the debian/ directory?
[05:08] <TomJaeger> Anyway, could someone please have a look at my package: http://revu.ubuntuwire.com/details.py?package=easystroke
[05:08] <RAOF> Hobbsee: You should fix xdg-open; that's what we use.
[05:08] <Hobbsee> RAOF: yes, but i could voluntell you to fix it..
[05:10] <RAOF> Right.  xdg-open is just plain stuffed.
[05:12] <RAOF> Ah.  The GNOME detection has been b0rked by new gnome-session.
[05:13] <RAOF> Hobbsee: You've got a kubuntu desktop handy, right?
[05:13] <Hobbsee> RAOF: er, no?
[05:13] <Hobbsee> actually, i might have a really old edgy version...
[05:13] <RAOF> Am I crazy?
[05:13] <Hobbsee> no?
[05:13] <RAOF> I was sure you did kubuntu stuff.
[05:14] <Hobbsee> i used to
[05:14] <Hobbsee> i haven't run kubuntu since hardy.
[05:14] <RAOF> Ah.  I'm merely out of date.
[05:14] <Hobbsee> i switched over a copule of days before hardy release
[05:14]  * Hobbsee has been slowly stepping out of kubuntu stuff
[05:15] <RAOF> Ok.  So: to anyone with a kubuntu desktop - does your environment contain DESKTOP_SESSION=kde?
[06:07] <crimsun> TomJaeger: again, it's not a rule but a recommendation.
[06:08] <dholbach> good morning
[06:08] <crimsun> 'morning
[06:09] <TomJaeger> crimsun, well anyway, I've added the license boilerplate now.
[06:10] <dholbach> hiya crimsun
[06:10] <TomJaeger> (the diff's 36k now)
[06:11] <RAOF> TomJaeger: You can't actually add license information for upstream.
[06:11] <TomJaeger> I am upstream
[06:11] <crimsun> (unless he's upstream)
[06:11] <RAOF> Aha :)
[06:21] <TomJaeger> So does anyone want to review it?  I've already looked through a few other submissions in order to anticipate common problems:  I removed commented lines, added a man page, improved the .desktop file and added license information to the source files, so hopefully this will be rather painless.
[06:25] <fabrice_sp> TomJaeger: if you are upstream, why not updating the orig file? This way, in the ubuntu diff file, we would only have the 'debian' directory stuff
[06:27] <TomJaeger> Is that really such a big deal?  I'd rather not modify files I've already released.
[06:27] <fabrice_sp> By the way, could someone review my mountmanage packaging? It's at http://revu.ubuntuwire.com/details.py?package=mountmanager. Thanks.
[06:29] <persia>  TomJaeger: For licensing, it's a big deal.  For nearly everything else, less so, especially if you commit the patches to your trunk for inclusion in the next release.
[06:30] <fabrice_sp> TomJaeger: the rule is not to modify anything outside debian directory inside a diff file. In the worst case, you should include patches in you debian directory to modify sources, but as it's about licensing, I think that nobody will ack that package...
[06:31] <persia> Remember that the orig.tar.gz must be independently redistributable.
[06:32] <ion_> I uploaded http://revu.ubuntuwire.com/details.py?package=compcache-setup which should have fixed the problems pointed out in the previous review. Anyone up for reviewing?
[06:36] <TomJaeger> persia, why would the orig.tar.gz not be independently redistributable?
[06:37] <TomJaeger> fabrice_sp, so you're telling me that there must not be any synergy effects if the packager and the upstream maintainer are the same person?
[06:38] <persia> TomJaeger: From backscroll, I thought you were patching licensing in the diff.gz.  That is usually not ideal, because if the licensing needs patching for redistribution, the unpatched orig.tar.gz would then not be redistributable.
[06:38] <persia> fabrice_sp: There's no rule about that.  There's no good reason *not* to modify things outside debian/ as long as the differences are well tracked.
[06:38] <ion_> Indeed
[06:39] <persia> Personally, I find that anyone who does this without a well-kept VCS is exceedingly annoying, but that's just me.
[06:39] <ion_> Such as in VCS commits
[06:42] <TomJaeger> persia, my current diff is not under revision control because I've made some changes in the development tree that preclude patches from applying to the released version.
[06:42] <TomJaeger> I actually created a patch by hand and then applied it to the packaging tree
[06:42] <ion_> tomjaeger: That’s what branches are for.
[06:43] <fabrice_sp> persia: that's what I've been told by apachelogger: for mountmanager package (sponsored by apachelogger), I spend a lot of time using quilt, to patch correctly the configure file (and some sources)
[06:43] <persia> TomJaeger: If you're diverging, I'd suggest either branches or debian/patches
[06:43]  * persia develops a strong distaste for pam_mount
[06:44] <persia> (or maybe just sbuild remounting /home 10 times during a build)
[06:44] <TomJaeger> ion_, darcs has trouble moving patches between branches when things are diverging, plus it's not like adding that license junk is in any way non-trivial.
[06:45] <TomJaeger> and why on earth would I spend half an hour or more to figure out how debian's patch system works?
[06:46] <persia> TomJaeger: So that if you later get distracted and someone else takes over maintenance, they don't need to spend several hours with you detangling the applied patches.
[06:46] <persia> Of course, if you're sure that won't happen until you're more in sync, it doesn't matter so much.
[06:46] <TomJaeger> all the patches are in the next version anyway, so that's a non-issue
[06:46] <persia> Well, uupdate will still show patch conflicts, but there are ways around that.
[06:48] <fabrice_sp> TomJaeger: why not just updating the easystroke-0.2.1.tar.gz file in sourceforge with the license changes? Maybe, it's a non sense, but it would be easier, as the changes are already in the next version.
[06:50] <TomJaeger> fabrice_sp, that is out of the question.  What I could do is release a new version just for this purpose, but I won't do that unless it's absolutely necessary
[06:51] <persia> TomJaeger: You could ask an archive-admin (on #ubuntu-devel), but historically, packages that patch licensing in diff.gz have been rejected.
[06:52] <TomJaeger> persia, okay, thanks, so I'll have to do it.
[06:53] <persia> TomJaeger: I suspect as much, unfortunately.  You can try without it, but I don't know that it will work.
[06:54] <TomJaeger> I'm not going to take any chances.  I'm sick of all the bureaucracy already.
[06:54] <persia> Yeah.  licensing is a lot of fuss :(
[06:55] <TomJaeger> I'm not actually changing licensing, though.  I'm just adding redundancy.
[06:58] <persia> TomJaeger: Yeah, well, unfortunately despite the efforts of many, copyright law isn't the same everywhere.  I live in one of the few places where the Berne Convention was adopted into law directly rather than laws being changed to match, and even that doesn't seem to work well for most people.
[07:02] <TomJaeger> What's going on here? easystroke: remote site does not even have current version
[07:04] <persia> TomJaeger: What is the output of uscan --report-status ?
[07:04] <TomJaeger> Newest version on remote site is 0.2.1, local version is 0.2.1.1
[07:04] <TomJaeger> easystroke: remote site does not even have current version
[07:04] <persia> OK.  What is first line of debian/changelog ?
[07:05] <TomJaeger> easystroke (0.2.1.1-0ubuntu1) intrepid; urgency=low
[07:06] <persia> OK.  Why 0.2.1.1 rather than 0.2.1 ?
[07:06] <TomJaeger> Because I don't change files once they're released.  That's shady.
[07:06] <persia> Essentially, either you need 0.2.1.1 on the remote site, or you need to just list 0.2.1 for the packaging.
[07:07] <TomJaeger> I just uploaded 0.2.1.1
[07:07] <persia> Yeah, that is shady.  Maybe release 0.2.1.1 on the main site, with a note that it's just licensing changes?
[07:07] <TomJaeger> http://sourceforge.net/project/showfiles.php?group_id=229797
[07:07] <persia> Oh, so it is there?  What is the match line in debian/watch?
[07:07] <TomJaeger> http://sf.net/easystroke/easystroke-(.*)\.tar\.gz
[07:08] <TomJaeger> maybe it takes some time to be available on the server?
[07:08] <persia> Might just be an issue with the debian sourceforge mirror management system used by the watch file.
[07:09] <TomJaeger> okay, that was it, it worked now
[07:09] <persia> Could take a bit to update.  Oh good :)
[07:12] <TomJaeger> Okay, the package should appear on REVU in just a few minutes
[07:26] <TomJaeger> okay, it's up now and my pbuilder^H^H^H^H PPA was able to build it.
[07:27] <TomJaeger> (Ended up having to change a file outside of debian/ anyway: The man page was still mentioned version 0.2.1)
[07:31] <persia> TomJaeger: Correcting a manpage is the sort of change to diff.gz that is considered good maintenance, rather than being risky.  Thanks for your flexibility.
[08:03] <\sh> moins
[08:04] <Laney> howdy
[08:19] <geser> Hi \sh
[08:24]  * persia is a little disturbed to read the REVU statistics, and encourages more people to comment on packages: there shouldn't be such concentration in the top 10.
[08:48] <emgent> moin
[09:40] <nxvl> hi all
[09:41] <nxvl> back in home again!
[09:41] <ion_> Hola
[09:47] <emgent> hi nxvl
[09:48] <nxvl> hi!
[10:02] <huats> hi nxvl
[10:02] <huats> !
[10:02] <nxvl> huats: hi!
[10:31] <laga> darn, even more people leaving motu-sru :(
[10:42] <DktrKranz> laga, yep :(
[10:59] <laga> DktrKranz: if you have a minute: what's still missing from bug #241402? i wrote that email to the MOTU mailing list.. do we need martin's ACK for the translations to be tested in hardy-proposed?
[10:59] <laga> hum, let me check if my mail went through
[11:00] <laga> no, it didn't go through. resending..
[11:01] <laga> it would probably help if i didn't reply to ubuntu-motu-bounces@..
[11:01] <DktrKranz> laga, pitti replied back. he's happy with update translations in universe SRUs (since he manages langpacks updates for main), so your debdiff should be ok. Do you have some mythbuntu guy to sponsor package in -proposed?
[11:02] <laga> yes, i saw his reply. i was just referring to his "assuming they're tested" bit.
[11:02] <laga> yes, i have a sponsor
[11:02] <laga> i just need the ACK ;)
[11:03] <DktrKranz> laga, good... I'll review it soon, then. thanks :)
[11:03] <laga> thank you
[11:04] <DktrKranz> are there some mechanism to test translations?
[11:05] <laga> setting $LANG accordingly and making sure the app doesn't crash? ;) seriosly though, i guess we'll have to find people who speak these (new) languages and hae them try it.. although that could be a painful process
[11:06] <DktrKranz> if Italian is one of these new languages, you've found a tester :)
[11:07] <laga> we do have an italian translation, not sure if it's new ;)
[11:08] <laga> i believe people need to be in a special team to be able to translate apps - so there should be some quality control regarding applicants.
[11:08] <DktrKranz> if they follow italian translation team rules, I trust them a lot
[11:10] <DktrKranz> laga, I see Intrepid tasks are not marked as Fix Released, is it fixed now?
[11:12] <laga> umm. i've committed all fixes, but not all of them are in intrepid yet
[11:12] <Syntux> can we use non-english characters in URLs, description or name in debian/control ?
[11:13] <DktrKranz> plans to release for intrepid soon?
[11:13] <laga> DktrKranz: we can do that if it's needed by the SRU policy. on the other hand, i'm currently rewriting mythbuntu-control-centre and that's what I planned to have uploaded next to intrepid
[11:15] <DktrKranz> laga, it's recommended to have intrepid tasks fixed, but if you plan to release fixes for intrepid before the release and keep track of status progress, I think it's safe enough to have a package in -proposed now.
[11:18]  * DktrKranz goes to lunch
[11:18] <directhex> i should really try & get an updated merge of mono into intrepid, but given the usual delays on u-m-s, it might only be out in time for 9.04
[11:39] <DktrKranz> directhex, try asking latest sponsor
[11:42] <DRebellion> Could somebody take a look at monkeystudio (http://revu.ubuntuwire.com/details.py?package=monkeystudio)? It's already had two advocations, but it was rejected by the archive admins for embedding libraries that were already available in the repos. That's fixed now, so it should be okay.
[11:46] <DktrKranz> laga, ACKed.
[11:51] <laga> thanks
[11:55] <k0p> hi all
[12:11] <k0p> DktrKranz, are you there?
[12:16] <k0p> I test my package in hardy x86, 64bits and works fine.
[12:16] <k0p> I can't reproduce norsetto error :/
[12:25] <sistpoty|work> hi folks
[12:26] <k0p> hi sistpoty|work
[12:27] <sistpoty|work> hi k0p
[12:29] <k0p> someone could review my package? http://revu.ubuntuwire.com/details.py?package=umit I already have a ack but I need another.
[12:32] <jmehdi> I've uploaded a new package for Webstrict (http://revu.ubuntuwire.com/details.py?package=webstrict) but I don't see it... can someone help me?
[12:33] <DRebellion> jmehdi, it takes five or so minutes to show up.
[12:33] <jmehdi> i've uploaded it several days ago... :(
[12:34] <jmehdi> is the version number taken into account?
[12:34] <DRebellion> jmehdi, did you login to revu using your launchpad account first?
[12:34] <DRebellion> you need to do that to get your keys synced to the new system
[12:34] <jmehdi> I don't think I did that
[12:35] <jmehdi> ok, I'll login, then should I have to upload it again ?
[12:36] <DRebellion> jmehdi, i don't know if you need to upload again. You should ask NCommander or RainCT. After logging in, you probably want to merge your old revu account with your launchpad one using the link at the top.
[12:37] <jmehdi> drebellion: ok I've merged my accounts
[12:37] <DktrKranz> k0p, I'm here now
[12:38] <sistpoty|work> jmehdi: I only see binary uploads of webstrect in the rejected queue, so please reupload (a source package)
[12:38] <Lutin> \sh: would you mind looking at the emacs21 merge ? the debdiff seeems to contain more than what's actually listed as retained changes
[12:40] <\sh> lucas: emacs21 or xemacs21?
[12:40] <jmehdi> sistpoty: I've uploaded that: "Uploading to revu (via ftp to revu.tauware.de):
[12:40] <jmehdi>   webstrict_1.0-0ubuntu1.dsc: done.
[12:40] <jmehdi>   webstrict_1.0.orig.tar.gz: done.
[12:40] <jmehdi>   webstrict_1.0-0ubuntu1.diff.gz: done.
[12:40] <jmehdi>   webstrict_1.0-0ubuntu1_all.deb: done.
[12:40] <jmehdi>   webstrict_1.0-0ubuntu1_i386.changes: done.
[12:40] <jmehdi> Successfully uploaded packages." is it ok?
[12:41] <sistpoty|work> jmehdi: nope, that's a binary upload
[12:41] <soren> jmehdi: No. You should only dput *_source.changes.
[12:41] <sistpoty|work> jmehdi: the _i386 from the changes file
[12:41] <k0p> DktrKranz, I test my package on hardy with amd64 and x86. It is systems clean. No bugs there.
[12:41] <sistpoty|work> jmehdi: please build your package/changes file with parameter -S (for source upload) and -sa (to include the orig.tar.gz) as parameters to dpkg-buildpackage/debuild
[12:42] <\sh> Lutin: do you have somehow the link to the merge report?
[12:42] <DktrKranz> k0p, I tested it on Intrepid, it seems good too
[12:42] <DktrKranz> I'll have another review now
[12:43] <DktrKranz> mh... no, not really now... later today
[12:43] <k0p> DktrKranz, ok :)
[12:43] <\sh> argl..it's my own merge ,->
[12:44] <jmehdi> sistpoty: thanks, I've uploaded it again
[12:44] <sistpoty|work> np
[12:44] <sistpoty|work> jmehdi: now it's a native package (is your .orig.tar.gz named correctly?
[12:44] <sistpoty|work> +)
[12:45] <k0p> DktrKranz, but I think the possible error on norsetto in hardy doesn't prohibits umit enter on intrepid. is it true?
[12:45] <DktrKranz> k0p, it can be fixed later, if it will show up
[12:46] <jmehdi> sistpoty: arf... is it because I changed the version? (I have a webstrict_1.0.orig.tar.gz and webstrict_1.0.0-0ubuntu1... files)
[12:47] <sistpoty|work> jmehdi: yep, looks like it. would be webstrict_1.0.0.orig.tar.gz then
[12:47] <sistpoty|work> jmehdi: but the good new is that the package should be on revu now :)
[12:48] <jmehdi> sistpoty: yep :)
[12:49] <\sh> Lutin: you can sync it...
[12:49] <\sh> Lutin: the only change was the libungif4-dev to libgif-dev change, which can go now, since we have this transitional package
[12:50] <jmehdi> sistpoty: ok, new package with 1.0 version, so it is clean...
[12:50] <\sh> Lutin: anyways..fileing sync req
[12:55] <\sh> Lutin: bug #255302
[12:59] <jmehdi> thanks sistpoty, all is fine ; now if someone could review my new package (http://revu.ubuntuwire.com/details.py?package=webstrict) :)
[13:10]  * ScottK thought we packaged emacs separately from Debian, but maybe that's just 22.
[13:23] <james_w> wireshark has a pretty bad rules file
[13:24] <ember> can someone have a look at http://revu.ubuntuwire.com/details.py?package=hamster-applet
[14:09] <Jazzva> Anyone willing to review sphinxbase and pocketsphinx in REVU :)? It has already been reviewed by RainCT, so current uploads correct what RainCT suggested. Thanks :). The links are <http://revu.ubuntuwire.org/details.py?package=sphinxbase> and <http://revu.ubuntuwire.org/details.py?package=pocketsphinx>
[14:24] <BUGabundo_work1> tseliot: hi
[14:25] <tseliot> BUGabundo_work1: hi
[14:25] <BUGabundo_work1> did the nvidia change from yesterday
[14:25] <BUGabundo_work1> got any regression reports?
[14:25] <BUGabundo_work1> I just rebooted and can't seem to use my nvidia card
[14:26] <BUGabundo_work1> actually I can't even open jokey to select the driver
[14:26] <tseliot> BUGabundo_work1: yes, a new driver was uploaded
[14:28] <BUGabundo_work1> can this be the cause why I'm at 800x600 ?
[14:29] <tseliot> what does this command say? sudo aptitude show nvidia-glx-173 | grep Version
[14:29] <tseliot> and of course I will also need your  /var/log/Xorg.0.log and xorg.conf
[14:30] <BUGabundo> tseliot: Version: 173.14.12-0ubuntu2
[14:30] <BUGabundo> I'll upload to pastebin
[14:31] <BUGabundo_work1> everything is "slugish"
[14:31] <BUGabundo_work1> the mouse is moving really slowly
[14:31] <BUGabundo_work1> metacity looks awfull
[14:33] <\sh> emgent: ping moin merge 1.7.1-1 from debian
[14:33] <sistpoty|work> kdub: just found a binary upload to revu (tv-grab) from you in the rejected queue... I'm removing it. please upload only source packages, thanks
[14:33] <sistpoty|work> tv-grab-dvd even
[14:34] <tseliot> BUGabundo_work1: oh, and make sure that the linux-headers for your kernel are installed
[14:34] <BUGabundo> http://paste.ubuntu.com/34760/
[14:35] <BUGabundo> tseliot: and http://paste.ubuntu.com/34762/
[14:35] <BUGabundo> looking for headers now
[14:36] <BUGabundo_work1> tseliot: headers are installed
[14:37] <tseliot> BUGabundo: add this line to the Device section of your xorg.conf:Driver "nvidia"
[14:37] <tseliot> BUGabundo: I mean, Driver "nvidia"
[14:37] <\sh> emgent: I filed a sync req of moin 1.7.1 because it fixes your security issue and some other problems like attachments
[14:37] <BUGabundo> humm getting DBUS erros while trying to lunch jockye-gtk
[14:37] <kdub> sistpoty|work: any idea what i did wrong?
[14:38] <kdub> i thought i did only upload source
[14:38] <sistpoty|work> kdub: well, only my standard line for this: when building a package, please use -S (to create a source package) and -sa (to include the .orig.tar.gz) as parameters for dpkg-buildpackage/debuild
[14:38] <tseliot> BUGabundo: you're using the "nv" driver. As regards Jockey you might want to contact pitti in #ubuntu-devel or (even better) file a bugreport against jockey
[14:39] <BUGabundo_work1> yeah
[14:39] <BUGabundo_work1> something with the lastest updates mess the system again
[14:39] <kdub> sistpoty|work: so using the -S flag will only make source then?
[14:39] <sistpoty|work> kdub: exactly
[14:39] <kdub> ok, sorry for doing the wrong thing
[14:39] <BUGabundo_work1> after that I had to run dpkg-recinfigure xserver -phigh just to get 1024
[14:40] <sistpoty|work> no problem kdub... was just a rm command on revu's server ;)
[14:40] <BUGabundo_work1> tseliot: so that's why it lost the nvidia driver
[14:40] <BUGabundo_work1> restarting X
[14:41] <BUGabundo_work1> tseliot: it fails... it just ask me to configure, because I'm left on a low-graphics mode
[14:42] <kdub> if i get an error, something like "no appropriate .orig in the parent dir", is that ignorable?
[14:42] <kdub> when doing debuild -S
[14:42] <tseliot> BUGabundo_work1: what does this command say? sudo modprobe nvidia
[14:44] <sistpoty|work> kdub: it usually means that you've got the name of the .orig.tar.gz wrong
[14:44] <k0p> someone can review my package? DktrKranz have already advocate it. http://revu.ubuntuwire.com/details.py?package=umit
[14:44] <BUGabundo_work1> tseliot: nothinh
[14:44] <BUGabundo_work1> tseliot: *nothing
[14:45] <tseliot> BUGabundo: ok, try to set the driver to "nvidia" then log out, log in and show me your /var/log/Xorg.0.log and /var/log/Xorg.0.log.old
[14:45] <BUGabundo_work1> tseliot: do I set by hand like I did last time, on xorg.conf?
[14:46] <tseliot> BUGabundo: yes, by hand
[14:49] <BUGabundo> tseliot: can is use:;
[14:49] <BUGabundo> 	Driver		"nvidia"
[14:50] <BUGabundo> 	Option		"NoLogo"	"True"
[14:50] <tseliot> BUGabundo: what do you mean?
[14:51] <BUGabundo_work1> if I can just add those lines to xorg
[14:53] <tseliot> BUGabundo_work1: yes, you can add them to the Device section
[14:54] <BUGabundo_work1> ok
[14:54] <BUGabundo_work1> pastebining the logs
[14:56] <BUGabundo> tseliot: http://pastebin.ubuntu.com/34769/ xorg.0.log
[14:56] <BUGabundo> tseliot: http://pastebin.ubuntu.com/34770/ xorg.0.log.old
[15:01] <tseliot> BUGabundo: both logs show that the vesa driver is in use. Type: "sudo updatedb && locate nvidia.ko" and show me the output
[15:02] <BUGabundo_work1> just a sec tseliot
[15:02] <BUGabundo_work1> pitti may have found another thing
[15:03] <bddebian> Heya gang
[15:04] <geser> Hi bddebian
[15:04] <bddebian> Heya geser
[15:05] <BUGabundo> tseliot: see private im, please
[15:13] <sistpoty|work> hi bddebian
[15:13] <bddebian> Heya sistpoty|work
[15:21] <jcastro> emgent: I can approve your mailing list today, just ping me when you resubmit it (check your mail) - thanks!
[15:26] <BUGabundo_work1> tseliot: all fine now
[15:27] <tseliot> BUGabundo_work1: great
[15:30] <BUGabundo_work1> now its bug 51054
[15:50] <emgent> \sh: i'm here :)
[15:51] <emgent> \sh: moin bug opened?
[15:51] <\sh> http://hg.moinmo.in/moin/1.7/rev/c4cf4327c96e
[15:52] <\sh> emgent: but after installing the debian package and checking that this patch is in 1.7.1 ... I wonder if I did something wrong or the patch actually doesn't work
[15:53] <emgent> uhm ok thanks \sh i go to take a look
[15:53] <\sh> emgent: anyways..I requested a sync..
[15:53] <emgent> ok nice
[15:54] <\sh> well, the error is not anymore with uploading but with displaying the stuff
[15:54] <emgent> \sh: debian fixed the bug that I found ?
[15:54] <\sh> emgent: upstream fixed the bug in 1.7.1
[15:54] <\sh> emgent: and debian has now 1.7.1
[15:55] <emgent> oh ok
[15:57] <emgent> uhm..
[15:58] <emgent> Thomas Waldmann had told me that upgrade to version 1.7 was not easy and automatic and that it was necessary to follow the documentation, but I did not detail
[15:59] <emgent> anyway this night i will try to install debian package in my devbox for see it
[16:00] <\sh> emgent: it works out of the box from 1.7.0 to 1.7.1...the migration is easy.
[16:00] <\sh> emgent: even the migration from 1.5.x (hardy) to 1.7.0 was quite easy...
[16:03] <emgent> \sh: ok
[16:06] <\sh> uh wow...new zend-framework 1.5.3.
[16:26] <siretart> sistpoty|work: thanks for taking over! :)
[16:26] <siretart> sistpoty|work: I've just wrote the email to ubuntu-motu
[16:26] <sistpoty|work> siretart: no problem
[16:26] <sistpoty|work> siretart: great
[16:27] <sistpoty|work> siretart: have a nice holiday ;)
[16:30] <lukehasnoname> A lot of people are leaving MOTU posts
[16:33] <Adri2000> DktrKranz or any other sru member: bug #243722 needs ack for gutsy (already got one for hardy)
[16:34] <DktrKranz> Adri2000, is your patch almost identical to hardy's one, isn't it?
[16:35] <Adri2000> DktrKranz: it's the same, but applied inline because there is no patch system in this version
[16:35] <DktrKranz> lukehasnoname, minimum wage, no holidays and bad badges on LP personal page, it's really a pain :)
[16:35] <DktrKranz> Adri2000, cumulative ACK :)
[16:36] <DktrKranz> please go ahead
[16:36] <ScottK> DktrKranz: I really appreciate you carrying the load on motu-sru.  It's a huge help for Universe.
[16:36] <DktrKranz> ScottK, it's not a problem, I really like SRUs and SRU process
[16:37] <Adri2000> DktrKranz: thanks
[16:37] <laga> what - someone likes SRU's? wow ;)
[16:38] <DktrKranz> laga, sometimes people are crazy, sometimes people are totally crazy, there are cases people like SRUs :)
[16:40] <ffm|sh> How do I get the rights to upload to universe?
[16:40] <ffm|sh> I'm working with the maintainer of a package, and a new version is coming out tomorrow.
[16:40] <ffm|sh> I'm tryng to figure out how to reupload.
[16:42] <james_w> ffm|sh: for that you can seek sponsorship of the upload
[16:43] <ffm|sh> james_w: is the magic word to-fetch-a-sponsor "plugh"?
[16:43] <ffm|sh> :)
[16:43] <james_w> rights to upload yourself are earned by showing skill and commitment to packaging
[16:43] <ffm|sh> james_w: Ok, how do I find a sponser?
[16:44] <james_w> ffm|sh: you prepare the upload, and attach your completed .diff.gz to the bug requesting an upgrade of the package, and then subscribe the "ubuntu-universe-sponsors" team to the bug
[16:44] <directhex> my subscribing ubuntu-universe-sponsors to a "new version plz" bug with the appropriate files attached to it
[17:06] <k0p> is frequently people request review on ubuntu-motu mailing list?
[17:07] <ffm|sh> k0p: hrm?
[17:08] <ScottK> k0p: Not usually.
[17:09] <k0p> ok :)
[17:09] <k0p> thanks.
[17:23] <k0p> someone can review my package? http://revu.ubuntuwire.com/details.py?package=umit
[17:26] <DRebellion> jmehdi, i don't know if you need to upload again. You should ask NCommander or RainCT. After logging in, you probably want to merge your old revu account with your launchpad one using the link at the top.
[17:26] <DRebellion> oops
[17:26] <DRebellion> :P
[17:27] <DRebellion> Could somebody take a look at monkeystudio (http://revu.ubuntuwire.com/details.py?package=monkeystudio)? It's already had two advocations, but it was rejected by the archive admins for embedding libraries that were already available in the repos. That's fixed now, so it should be okay.
[17:34] <ffm|sh> how hard is it to change the maintainer of a package to a team?
[17:39] <NCommander> ffm|sh, annouce it ont ubuntu-devel, and upload a new revision with the changed Maintainer.
[17:39] <ffm|sh> NCommander: does that mean that all members of that team have the irght to upload?
[17:40] <NCommander> ffm|sh, well, anyone can upload any package as long as they're an MOTU or higher
[17:40] <NCommander> ffm|sh, what are you trying to form a team for?
[17:42] <DktrKranz> ffm|sh, please note Ubuntu hasn't Maintainer concept (like Debian) and MOTUs and core-devs can upload changes to almost every packages
[17:43]  * NCommander was going to point that out
[17:43] <NCommander> Debian allows non-maintainer uploads, but its usually frowned upon, hence why you have teams in Debian.
[17:45] <ffm|sh> NCommander: ~sugarteam is to be the maintainer of the "sugar-*" package
[17:45] <NCommander> ffm|sh, is it an Ubuntu specific package, or is it getting maintained in Debian
[17:46] <ffm|sh> NCommander: Currently there are debian packages and ubuntu packages, they were made by different people, we don't import from each other IIRC
[17:47] <ScottK> ffm|sh: Why not?  We should leverage Debian's work and contribute enhancements back to them unless there is a very good reason not to.
[17:48]  * NCommander agrees with ScottK 
[17:48] <NCommander> Every package I do gets an offer to import my work into Debian
[17:48] <NCommander> Most people turn me down, but some of my work has got into the Debian GNOME team
[17:48] <ffm|sh> ScottK: Lack of orginization.
[17:49] <ScottK> Then I'd say rebase off of Debian first and then see where you are.
[17:49] <ffm|sh> ScottK: I'd do it myself, but debian doesn't allow pseudononymous contributors AFAICT.
[17:49] <ScottK> You can send patches to BTS.
[17:49] <broonie> You certainly couldn't be a direct maintainer but if there's ateam it only needs one person to be able to do uploads
[17:50] <ScottK> ffm|sh: Let's put it this way...  If I grep'ed out a list of all the sugar packages and then fired up requestsync, how much harm would it cause to the Ubuntu 'sugar' experience?
[17:50] <ffm|sh> ScottK: we have a new release tomorrow, should our workflow be "wget debian's source, update, build, submit patch to both?"
[17:51] <ffm|sh> ScottK: I'm not really sure.
[17:51] <ffm|sh> ScottK: I hjavn't used that application.
[17:51] <ScottK> ffm|sh: I'd suggest dget Debian's packages and then package for Ubuntu a -0ubuntu1 version based on that.
[17:52] <ScottK> requestsync is a script to ask for packages to be sync'ed from Debian to Ubuntu.
[17:52] <ScottK> Where you find differences in the packaging that are needed, file bugs with patches in Debian.
[17:52] <ffm|sh> ScottK: Is there any docs on how I'd do that?
[17:52] <ScottK> Do which?
[17:54] <ffm|sh> ScottK: Here's the question, can I update the ubuntu package and have debian sync with that?
[17:55] <ScottK> ffm|sh: In theory, but in practice they are upstream.
[17:55] <ffm|sh> :(
[17:55] <ScottK> So take their packaging as a basis for your work and then document your changes from it.
[17:56] <ScottK> Where those changes relate to Ubuntu unique things, that's fine, but where the changes would also benifit Debian, file a bug with a patch.
[17:56] <ffm|sh> ScottK: OK, so if I sync with latest debian, then a new release comes out (from upstream-of-debian), who do I submit the patch to?
[17:56] <Lutin> \sh: the gif/ungif thing was actually not the only change when you look at the diff, hence my question
[17:56] <broonie> ffm|sh: Talk to the Debian maintainer and work with them.
[17:57] <broonie> ffm|sh: Ideally between the two of you you will be able to get the new version into Debian and then work from there.
[17:57] <ScottK> ffm|sh: Listen to broonie.
[18:00]  * sistpoty|work calls it a day and heads home... cya
[18:00] <ffm|sh> broonie: Ok.
[18:01] <ffm|sh> ScottK: How can I see the ubuntu-spesific modifications that have been made to a package, so I can see if I'll lose anything in a sync?
[18:01] <NCommander> ffm|sh, debdiff between the Debian and Ubuntu versions
[18:02] <ScottK> ffm|sh: Grab both the debian and ubuntu packages and then use debdiff to compare them.
[18:02]  * ScottK high fives NCommander.
[18:03]  * NCommander is high fived
[18:03] <NCommander> Neat
[18:03] <ffm|sh> ScottK or NCommander The debian version is newer than the ubuntu one. How can I get the older version? (where they have the same version number)
[18:03] <NCommander> ffm|sh, unless the older one is in etch or lenny, its gone
[18:03] <NCommander> I think retention on the FTP servers are two weeks, then old packages are purged via dak, and then removed when each mirror rsyncs
[18:04] <broonie> Try snapshot.debian.net
[18:04]  * NCommander learns of a new handy debian service
[18:04]  * ScottK was about to hand ffm|sh http://snapshot.debian.net/ , but broonie got there first ...
[18:04] <NCommander> ScottK, its amazing how many SRU motus we're loosing -_-;
[18:05] <NCommander> It's a domino effect
[18:05] <ScottK> Personally I found the bug volume overwhelming.  LP's U/I and I don't get along and it was just too much for me.
[18:06] <ffm|sh> Hrm...
[18:06] <ffm|sh> I see the binaries, but no source at http://snapshot.debian.net/archive/2008/03/11/debian/pool/main/s/sugar/
[18:06] <NCommander> Maybe its time someone writes a standalone app based off launchpadlib like the GNAT standalone UI
[18:07] <milosz_> hello, i've got a question regarding creation of Ubuntu packages
[18:08] <milosz_> i've created and set up the debian/ dir, and now when building a package (it's a libs package) everything is allright, except that the headers and .pc files are not split into the -dev package
[18:08] <milosz_> i'm at a loss on how to do that and i couldn't find instructions on it
[18:10] <ffm|sh> broonie or ScottK , any idea wher the source is?
[18:10] <ScottK> ffm|sh: For what?
[18:10] <ScottK> Ah.
[18:11] <ScottK> ffm|sh: Try dget -x http://snapshot.debian.net/archive/2008/03/11/debian/pool/main/s/sugar/sugar_0.79.0-1.dsc
[18:12] <alex-weej> milosz_: you packaging AudioSource?
[18:13] <milosz_> alex-weej, yeah
[18:13] <milosz_> and the dependencies
[18:13] <milosz_> pywebkit, taglib-gio
[18:14] <ffm|sh> ScottK: thx
[18:17] <milosz_> ok i found the .install files, but they are being ignored it seems
[18:25] <bobbo> can packages in Universe build-depend on Multiverse packages?
[18:27] <coolbhavi> dad grab merge.sh not working http://pastebin.com/d13024b4a
[18:27] <coolbhavi> please help
[18:28] <ffm|sh> ScottK: when  I run requestsync, I am told that my DEBEMAIL isn't defined.
[18:28] <bobbo> ffm|sh: export DEBEMAIL="youremail@host.com"
[18:29] <ScottK> ffm|sh: Don't worry so much about running requestsync.  You need to understand the differences in the packaging and see if there are Ubuntu unique things that need to be preserved.
[18:29] <ffm|sh> ScottK: I've talked with my group, they say there arn't any.
[18:29] <ScottK> ffm|sh: Also remember to use -s if you run requestsync, since you'll need to be sponsored.
[18:30] <ffm|sh> ScottK: Don't worry, I will.
[18:31] <coolbhavi> Is there anything specific setting up dad compared to MoM?
[18:31] <ffm|sh> ScottK: How do I do that for, like 8 packages?
[18:31] <ffm|sh> ScottK: I'd rather not have to set up a separate sync request.
[18:31] <milosz_> sorry but what do i need to do in order to have a separate -dev package?
[18:31] <ScottK> ffm|sh: You have to do it per package.
[18:32] <ffm|sh> argh....
[18:32] <stefanlsd> When doing a merge - Im still struggling how to figure out what patches have already been applied and what still needs to be merged - is there a procedure for this?
[18:35] <ffm|sh> ScottK: For some reason requestsync is using my personal, non-pseudononymous key for submissions (good thing launchpad rejected that mail)
[18:35] <ffm|sh> ScottK: any idea how to fix?
[18:35] <ScottK> ffm|sh: Use -k and the key id
[18:35] <ScottK> see man requestsync for details.
[18:36] <joaopinto> Can someone review and advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
[18:37] <ffm|sh> ScottK: Ok. Is https://lists.ubuntu.com/archives/ubuntu-sugarteam/2008-August/000023.html a fairly good reason not to sync with debian?
[18:39] <slayton> when compiling a binary using the standard procedure (./configure, make) I get a binary named X  is there anyway that when I package the binary into a deb I can get the binary renamed to something like MyPrefix-X?
[18:39] <broonie> slayton: Your rules file can run whatever shell commands it wants.
[18:39]  * ScottK looks
[18:40] <slayton> broonie, so I can rename the binary in my rules file?
[18:40] <ScottK> Maybe.
[18:40] <DRebellion> slayton, yes
[18:41] <ffm|sh> ScottK: obviously, if we dont merge, it'll increase our workload.
[18:42] <ScottK> ffm|sh: It seems very odd to me that CDBS is doing a major rewrite just after Lenny freezes.
[18:42] <ScottK> Urgh.
[18:42] <ScottK> ffm|sh: Are the new Debian sugar packages being pushed to Unstable or Experimental?
[18:43] <ffm|sh> ScottK: Yes.
[18:43] <ScottK> Both?
[18:43] <ScottK> It was an 'or' question.
[18:43] <slayton> when I write commands in the rules dir I have to write them as if I'm in the same dir as the debian directory right?
[18:45] <milosz_> i'm trying to add all header and the .pc file of the lib into the -dev package and the shared libs into the main package
[18:45] <joaopinto> slayton, no, you should assume they are ran from the source dir
[18:45] <milosz_> however, i get from dpkg-buildpackage:
[18:45] <joaopinto> run
[18:46] <milosz_> dh_install: taglib-gio-dev missing files (usr/include/taglib-gio/*), aborting
[18:46] <milosz_> i don't get the error, there is an .install file taglib-gio-dev.install but i don't understand what i have to to in order for dh_install to find the files (they are getting all installed into debian/tmp, perhaps that's not right?)
[18:48] <slayton> so would a simple command like " mv ../debian/<package>/usr/bin/X ../debian/<package/MyPrefix-X" placed at the end of my rules file do the trick for renaming the file?
[18:48] <milosz_> ok i understand that if it doesn't feel like really want to know this no one will tell me so let me state that yes i'd really like to know :>
[18:49] <Adri2000> coolbhavi: it's because checkinstall's merge is broken on DaD
[18:50] <ffm|sh> ScottK: unstable.
[18:50] <lukehasnoname> does ubuntu-dev-tools have all I need to package and patch software?
[18:50] <ScottK> lukehasnoname: No.
[18:50] <Adri2000> coolbhavi: see the /!\ on http://dad.dunnewind.net/universe.php
[18:50] <ffm|sh> ScottK: will it be hard to maintain if we import from debian?
[18:50] <ScottK> ffm|sh: Then I'd say don't worry about it.  The automated merge/sync tools should deal with those problems.
[18:50] <ScottK> Mostly anyway.
[18:51]  * milosz_ thinks it's a typical lvl50-required-to-reach-lvl50-situation
[18:51] <ffm|sh> 13:42  ScottK$ ffm|sh: Are the new Debian sugar packages being pushed to Unstable or Experimental?
[18:51] <ffm|sh> 13:42  ScottK$ ffm|sh: Are the new Debian sugar packages being pushed to Unstable or Experimental?
[18:51] <ffm|sh> ooops.
[18:53] <coolbhavi> Thanks Adri2000
[18:54] <bobbo> Can Universe packages Build-Depend on Multiverse packages?
[18:54] <ScottK> bobbo: No.
[18:54] <ffm|sh> bobbo: no.
[18:55] <bobbo> ScottK: ffm|sh thanks1
[18:55] <bobbo> s/1/!/
[18:58]  * NCommander never got why the non-free software section gets the cooler name
[18:58] <lukehasnoname> multiverse?
[18:59] <lukehasnoname> heh
[18:59] <lukehasnoname> free should have been called galaxy and non-free should have been called universe
[19:01] <Kopfgeldjaeger> DktrKranz: hi. I uploaded a new gtkhash version to revu (after norsetto's comments). Looks like I shouldn't specify the author/license for each source file as it's the same for all. Maybe you could... well ;) If you've got time: http://revu.ubuntuwire.com/details.py?package=gtkhash
[19:02] <DktrKranz> Kopfgeldjaeger, I fear I have no time for today, I'm buried in SRU process and I'd like to finish bug list soon, sorry :(
[19:03] <ffm|sh> How do I request a rename?
[19:03] <Kopfgeldjaeger> OK, no problem ;)
[19:04] <ffm|sh> ScottK: see above
[19:05] <ScottK> ffm|sh: Sorry, busy with $WORK right now.  Someone else will need to answer.
[19:06] <ffm|sh> kk.
[19:11] <k0p> someone can review and advocate my pacakge? http://revu.ubuntuwire.com/details.py?package=umit
[19:11] <Adri2000> is it possible to backport from a stable release?
[19:12] <Adri2000> eg. backport from feisty to dapper?
[19:19] <ScottK> Adri2000: Yes, but be very clear in your request so the archive admins don't miss it.
[19:21] <Adri2000> ok
[19:23] <slayton> in my rules file I added an ls command to list the contents of usr/bin then I issued the mv command to rename the file... it didn't work: here is the output of the dpkg-buildpackage  http://pastebin.com/m2fa1ee8c  I'm really getting confused to why this isn't working....
[19:23] <slayton> I did this after the build command
[19:24] <slayton> http://pastebin.com/m540580d3  <-- this is a better pastebin
[19:25] <DRebellion> slayton, have you explicitly created /usr/bin?
[19:25] <DRebellion> wait
[19:25] <DRebellion> it must already be there
[19:25] <DRebellion> :P
[19:25] <slayton> no... but it already exists.... actually I just noticed a spelling error... GRR!!! Sorry
[19:26] <tuxmaniac> wiki seems to be gone crazy!
[19:26] <slayton> let me try again
[19:26] <DRebellion> slayton, yep, there is ; )
[19:26] <slayton> DRebellion, i've become to reliant on tab completion that I make mistakes when I don't have it :-p
[19:26] <DRebellion> slayton, same.
[19:30] <slayton> DRebellion, if I want to  include one or two binaries in a package but  the standard make command builds others that I don't want... is the easiest way to remove the unwanted binaries just delete them in the rules file or is there a specific way to exclude things?
[19:30] <DRebellion> slayton, just delete them in the rules file.
[19:31] <slayton> ok great
[19:31] <slayton> thanks
[19:31] <DRebellion> slayton, you can do pretty much anything in the rules file to make debian/tspikes/* exactly how you want it.
[19:32] <slayton> DRebellion, thanks...  i'm pretty new to building programs from source let alone packaging, but its the task that was assigned me...
[19:32] <slayton> I really appreciate the help i get here
[19:36] <tuxmaniac> wgrant: Hi. Can you please subscribe Avogadro to MOTU Science team in LP?
[19:54] <stefanlsd> running a debuild -S -sa and im getting - checking for X... configure: error: Can't find X includes. Please check your installation and add the correct paths!.  Anyone have any suggestions?
[19:54] <DRebellion> stefanlsd, are you running ./configure in the clean target?
[19:56] <stefanlsd> DRebellion:  There is something -  if test ! -f $(CURDIR)/Makefile;then \   CFLAGS="$(CFLAGS) -Wl,-z,defs" ./configure $(configkde); \ fi    (this is a merge from debian)
[19:57] <DRebellion> stefanlsd, that's just odd. You would have to tell us what $(configkde) points to.
[19:58] <stefanlsd> DRebellion: Only thing i see is - admin/debianrules:  print STDOUT "configkde=$enable_debug $enable_final --disable-rpath --prefix=\$(kde_prefix) --libexecdir=\$(kde_bindir) --sysconfdir=\$(sysconfdir) --libdir=\$(kde_libdir) --includedir=\$(kde_includedir) --with-qt-includes=/usr/include/qt3 --mandir=\$(mandir) --infodir=\$(infodir) --with-xinerama\n";
[19:59] <DRebellion> stefanlsd, right. Maybe someone else knows why they would be running configure in the clean rule. *shrug*
[19:59] <stefanlsd> DRebellion: hehe. yeah... seems weird :)
[20:01] <stefanlsd> DRebellion: yeah. if i hash it out -it builds. let me see if i can find who put the merge in.
[20:01] <ffm|sh> Is it bad form to ask for a sponser to sync on IRC?>
[20:01] <ffm|sh> https://bugs.edge.launchpad.net/ubuntu/+source/sugar/+bug/255432
[20:09] <james_w> ffm|sh: it's rare, sync requests are normally processed quite fast anyway
[20:10] <ffm|sh> james_w: how fast is "quite"?
[20:10] <ffm|sh> james_w: and how do I ask for a package-renaming?
[20:10] <ffm|sh> (different package)
[20:11] <james_w> um, you do it and ask for sponsorship I think, I've never done it though
[20:11] <james_w> "quite" is within a few days in my experience
[20:19] <squinky86> I uploaded a package to revu, but it's not showing up in my account on revu
[20:20] <nxvl> squinky86: it's not automatically
[20:20] <nxvl> squinky86: it takes some minutes untill you see the package
[20:20] <squinky86> nxvl: the wiki said '5'. It's been about 20.
[20:20] <nxvl> squinky86: package name?
[20:21] <squinky86> nxvl: lrzip
[20:21] <fabrice_s1> squinky86: did you connect with OpenID, and merge your old REVU account?
[20:21] <squinky86> I uploaded it again about 7-8 minutes ago just to be sure.
[20:21] <squinky86> It's a new account all-around.
[20:22] <nxvl> squinky86: have't you get an error e-mail?
[20:22]  * persia checks the queue
[20:22] <squinky86> I have not received an email.
[20:22] <stefanlsd> Im doing a merge - can i just modify the rules to remove something, or do i need to write a patch to do the remove?
[20:23] <squinky86> I've never built a debian/ubuntu package before, so I've accepted that I'm doing something wrong, and I'm trying to follow the documentation on the wiki.
[20:23] <persia> squinky86: Is your GPG key registered with launchpad?
[20:23] <squinky86> persia: Yes, and I have signed the code of conduct.
[20:24] <persia> squinky86: REVU isn't smart enough to check that :)
[20:24] <squinky86> :). As long as it can find my package, REVU can be as dumb as it wants!
[20:25] <fabrice_s1> squinky86: and did you log in REVU?
[20:25] <persia> squinky86: I found your package: just trying to figure out why it was rejected.
[20:26] <squinky86> fabrice_s1: afaik
[20:26] <squinky86> persia: Thank you!
[20:26] <persia> squinky86: What's your LP ID.
[20:27] <squinky86> persia: should be squinky86
[20:27] <persia> nick consistency is always good :)
[20:27] <persia> Hmm.. BBAB1A83 seems right :(
[20:28] <squinky86> persia: Look for a silly mistake. I gaurantee you it was something dumb that I did or overlooked.
[20:28] <persia> squinky86: By the way, the package as is probably needs work: at least I suspect it oughtn't be native.
[20:29] <squinky86> persia: What do you mean "native"?
[20:29] <persia> Also should close a bug with the initial changelog
[20:29] <squinky86> persia: You're confusing the newbie.
[20:29]  * persia stops reviewing the .changes file, and looks more for the actual issue
[20:32] <persia> squinky86: Seems your key hasn't been imported.
[20:33] <squinky86> persia: Any chance you could tell me how to do that, or point me to the relevant docs?
[20:33] <persia> That said, I'm not that familiar with the new verison of REVU, and don't know the best way to force import.
[20:33] <squinky86> persia: Ah, it's an issue with revu?
[20:33] <persia> squinky86: I think it's supposed to happen automatically when you log in.
[20:34] <persia> Well, the package has some issues: you'll want to run lintian -iIv lrzip_0.23_source.changes
[20:34] <persia> You'll probably also want to set the version in debian/changelog to 0.23-0ubuntu1
[20:34] <slayton> Is there a way for me to get the Intrepid DBUS sources with the debian directory intact?
[20:34] <persia> slayton: apt-get source
[20:35] <slayton> persia: I forgot to mention i'm running Hardy
[20:35] <squinky86> persia: Thank you. I'll definitely do that. Will logging out of launchpad and back in 'import' my key?
[20:35] <persia> slayton: Well, you can either download from https://launchpad.net/ubuntu/+source/dbus, or add intrepid source stanzas to /etc/apt/source.list and use apt-get source
[20:36] <lukehasnoname> slayton: apt-get dist-upgrade; apt-get source <_<
[20:36] <persia> squinky86: Not logging in and out of LP.  Logging into REVU.
[20:36] <persia> visit revu.ubuntuwire.com
[20:36] <persia> lukehasnoname: That is inherently dangerous for a wide range of use cases.
[20:36] <lukehasnoname> I know
[20:37] <lukehasnoname> notice the sly eyes
[20:37] <slayton> persia, I downloaded the source from launchpad but it doesn't contain the debian directory....
[20:38] <persia> slayton: What URL?
[20:38]  * squinky86 installs lintian
[20:38] <persia> lukehasnoname: Is that what they were.  I'm not sure everyone understands emoticons well.
[20:39] <slayton> persia, https://launchpad.net/ubuntu/intrepid/+source/dbus/1.2.1-2ubuntu9/+files/dbus_1.2.1.orig.tar.gz
[20:39] <slayton> persia, and I'd rather not add the intrepid repo to my hardy apt-sources unless I have to
[20:39] <persia> slayton: OK.  Near there you ought see links for .dsc and .diff.gz: you need all three parts.
[20:40] <slayton> k
[20:41] <slayton> persia, how then do I use the .dsc and .diff to add the debian dir?
[20:43] <slayton> persia, i got it never mind
[20:43] <persia> slayton: dpkg-source is handy, no?
[20:43] <slayton> oh... i used patch...
[20:44] <persia> Ah.  That usually works, but is less reliable.  dpkg-source -x foo.dsc will do the checksum verifications, and deal with tarballs that don't unpack where one might expect.
[20:45] <NCommander> Is it just mean, or the wiki dead?
[20:46] <squinky86> NCommander: I can't get to it either. It's been like this off and on all day.
[20:46] <DRebellion> NCommander, yep, what squinky86 said.
[20:47] <squinky86> persia: This lintian tool is very frustrating. I keep fixing an issue that it raises, but it won't go away!
[20:48] <persia> squinky86: Did you log into the REVU site yet?  Also, which issue?
[20:48] <squinky86> persia: Yes, I've relogged into REVU. The issue with lintian is with the distclean target, starting out, "A rule in the debian/rules file for this package calls the package's..."
[20:49] <NCommander> squinky86, you do know you need to rebuild the source package before Lintian can detect changes, right?
[20:49] <squinky86> NCommander: with "dpkg-buildpackage -S -sa -rfakeroot", correct?
[20:50] <NCommander> squinky86, that would do the trick
[20:50] <persia> squinky86: BBAB1A83 has now been imported.  Your next upload should work.
[20:50] <squinky86> persia: Thanks.
[20:50] <NCommander> persia, was there an issue with the keysyncer?
[20:50] <persia> Also, `debuild -S -sa` is the short why to type that command :)
[20:51]  * NCommander has always called dpkg-buildpackage directly
[20:51] <NCommander> Is there any advantage to using debuild over dpkg-buildpackage?
[20:51] <persia> NCommander: No idea: the key wasn't in the keyring for the last upload.  A fresh login to REVU fixed it.
[20:51] <persia> NCommander: it's fewer keystrokes?
[20:51] <NCommander> persia, its possible LP lagged on updating the RDF data files
[20:51] <NCommander> persia, or the key wasn't on the LP keyservers yet
[20:51] <persia> (debuild calls dpkg-buildpackage, and passes most of the options)
[20:52] <persia> NCommander: Maybe.  I didn't look that hard.
[20:52] <persia> By the way, is there updated documentation for REVU admins available yet?
[20:52] <NCommander> persia, I made some basic changes to the pages on the wiki
[20:52] <NCommander> persia, was there a revu admin doc I missed?
[20:54] <persia> NCommander: Well, the previous guide to being a REVU admin was an email from sistpoty to ubuntu-motu months and months ago.  Talks about the use of /srv/revu-production/bin/* and common tasks to support uploaders, clean up issues, etc.
[20:54] <NCommander> persia, that shouldn't have changed at all expect that fetch-launchpad-keys doesn't exist anymore
[20:55] <persia> I'm guessing some of that has changed (I know alter-user changed).
[20:55] <persia> Err, it did.
[20:55] <NCommander> persia, not really, same command syntax
[20:55] <persia> Not for alter-user.
[20:55] <squinky86> GRR! The "distclean" message is STILL there. It says it's on line 48 of debian/rules, which I changed to its suggestion: "[ ! -f Makefile ] || $(MAKE) clean"
[20:55] <persia> Maybe it's just that one.
[20:55] <NCommander> persia, there were changes to alter-user to remove the password functionality
[20:55] <persia> Also, I'm presuming we oughtn't willy-nilly import keys anymore, as it won't match unless it as an openid link.
[20:56] <persia> s/as/has/
[20:56] <NCommander> persia, nah, its pretty smart, if they key is already in the ring, it will make the assiocation on first login
[20:57] <NCommander> persia, its just scripting GPG is evil; all its output is also ending up in the apache error_log -_-;
[20:57] <squinky86> I'm a little upset - if I can't even fix the first issue that lintian spits out at me. Is there somewhere that details all of lintian's possible messages and how to fix them?
[20:57] <NCommander> squinky86, run lintian -v *dsc file*
[20:57] <persia> NCommander: Right, but in a case like squinky86, if I imported the key with revu-key, would it have fixed it, or would it still require re-login?
[20:57] <persia> No.  Run lintian -iIv : -v isn't enough.
[20:58] <NCommander> persia, no, it would have rejected since the association isn't there
[20:58] <NCommander> (the register-uploads script got a massive rewrite in sections)
[20:58] <squinky86> Oh crud, I see what I did now. Changing the package version to "0.23-0ubuntu1" also changed the output files generated from building... I feel dumb now.
[20:58] <persia> NCommander: Right.  That's a behavioural change, even if the code didn't change.
[20:58] <ffm|sh> persia: is it OK for me to seek sponsership via IRC?
[20:58] <persia> Would you mind writing up a new summary?
[20:58] <persia> ffm|sh: For what sort of thing?
[20:59] <ffm|sh> persia: debian syncs
[20:59] <persia> ffm|sh: Generally we discourage specific request for sponsorship for those, unless one is specifically blocking something else you are chasing.
[21:00] <ffm|sh> persia: yeah, I'm trying to get it synced, so that when the new upstream comes out tonight, I can update our packages and submit a debdiff.
[21:01] <NCommander> ffm|sh, for syncs, you don't submit debdiff, just put a sync request in
[21:01] <ffm|sh> NCommander: I know. After the sync, I'm going to give a debdiff for the new upstream (non-debian) version.
[21:02] <james_w> ffm|sh: what's the point in syncing first if you are just going to upload a new version straight away?
[21:02] <ffm|sh> james_w: to rebase on debian.
[21:02] <ffm|sh> james_w: ATM we arn't using debian packaging for this package.
[21:03] <james_w> making the update to new version easier to understand for reviewers could be a reason I guess, but you can provide the diff to Debian seaprately
[21:03] <james_w> yeah, but you are going to diverge from Debian again in a few hours anyway.
[21:03] <james_w> There's no reason why you can't base your packaging of the new upstream on Debian's current version without it being synced to Ubuntu first
[21:04] <ffm|sh> james_w: OK, question then: If we sync with debian, and don't make any ubuntu-spesifc changes, will the new debian versions be auto-downloaded?
[21:04] <ffm|sh> james_w: ie. if we synced, and debian made a new change, does that change get passed along?
[21:04] <james_w> no, not currently, as we are past Debian Import Freeze
[21:04] <james_w> you would have to request it manually
[21:05] <james_w> they would be once Intrepid is released though
[21:05] <persia> ffm|sh: If you're planning to update tomorrow, why bother with a sync?
[21:06]  * persia stops echoing james_w
[21:06] <ffm|sh> james_w: ah, makes sense.
[21:06] <james_w> persia: it was a pre-echo of you
[21:07] <persia> Note that a manual request for a sync *after* the Debian update would be much more interesting than either the current sync request or the planned update (if such a Debian update doesn't conflict with the Lenny freeze)
[21:07] <ffm|sh> james_w: tomorrow, there will be updates to a whole bunch of related packages in debian. I have to make a separate req for _each_, even though it's the same project?
[21:07] <james_w> ffm|sh: yes, if they are different source packages
[21:07] <james_w> you may want to look at "requestsync" from the ubuntu-dev-tools package
[21:08] <james_w> "requestsync -s <package> intrepid" will automate a lot for you
[21:08] <james_w> the "-s" is important
[21:09] <nxvl> emgent: around?
[21:09] <ffm|sh> james_w: Yeah, I already sumbitted a request that way. I guess I should close it, right?
[21:10] <james_w> ffm|sh: if you are going to look to get the new version in tonight then I would suggest so, yes.
[21:11] <jpds> ffm|sh: Or make changes to the title/body of the existing bug.
[21:11] <squinky86> persia: I have fixed all the issues that I know how. The remaining ones are: 1) "You've specified an unknown target distribution for your upload in the debian/changelog file...", 2) "This source package is not Debian-native but it does not have a debian/watch file..." Could you please direct me to documentation that can fix these issues?
[21:11] <persia> squinky86: Which target distribution does it complain about?
[21:11] <NCommander> squinky86, make sure its "intrepid" instead of "unstable" in your changelog
[21:11] <persia> Also, man uscan
[21:11] <stefanlsd> Is anyone able to take a look at a debdiff for a merge im trying - i feel like i may be complicating it...
[21:12] <squinky86> persia: "Your version string suggests this package is for Ubuntu, so your distribution should be one of intrepid, hardy, gutsy, feisty, edgy or dapper."
[21:12] <squinky86> How do I specify the version string?
[21:13] <persia> squinky86: In the changelog, as NCommander specificed.
[21:13] <persia> stefanlsd: Pastebin?
[21:14] <squinky86> NCommander, persia: thanks!
[21:14] <stefanlsd> persia: thanks. will do - just running it through pbuilder quick...
[21:14] <ffm|sh> lol, there was a pending request for ages before I came along: https://bugs.edge.launchpad.net/ubuntu/+source/sugar/+bug/246017
[21:15] <stefanlsd> persia: http://pastebin.ubuntu.com/34880/
[21:18] <persia> stefanlsd: Debian has dh_iconcache ?!?
[21:19] <stefanlsd> persia: dh_icons...   (it was renamed...)
[21:20] <stefanlsd> oh
[21:20]  * squinky86 waits 5 minutes to see if it worked this time...
[21:20] <stefanlsd> it wasnt renamed... is what you are saying?
[21:21] <jpds> stefanlsd: _iconcache was replaced by _icons some time ago.
[21:21] <k0p> hi norsetto :)
[21:21] <persia> stefanlsd: Currently, neither Debian nor Ubuntu have dh_iconcache.  In the past, there was a dh_iconcache only in Ubuntu.  It would have made sense in the context of an Ubuntu package to replace dh_iconcache with dh_icons, but I would be surprised to see that as a "remaining change".
[21:21] <norsetto> hi k0p
[21:22] <persia> stefanlsd: I also don't see that as a change later in the diff, I only see something that could be described as "Added dh_icons".
[21:22] <stefanlsd> jpds / persia: thanks. you guys are right.  an ubuntu1 release made it dh_iconcache, and then an ubuntu2 release fixed it to dh_icons.  so my changelog entry is misleading...
[21:22] <k0p> norsetto, today I test several package of umit. Compile on hardy with x86, and amd64. Nothing happens. Works fine ever.So can you help me reproduce bug?
[21:22] <stefanlsd> persia: nodnod. will fix that. thanks
[21:23] <norsetto> k0p: how?
[21:23] <persia> stefanlsd: More generally, you should look through all the "remaining changes" and make sure they are really "remaining changes".  Some might need rewording.  Some might have been adopted, and can be dropped.
[21:24] <k0p> norsetto, strace :X
[21:24] <k0p> gh
[21:24] <slayton> so I'm trying to build a dbus daemon with statically linked libs...  so I added "--disable-shared" to the configure script in the rules files but then when I run dpkg-buildpackage I get an error : http://dbus.pastebin.com/m43377587
[21:24] <k0p> may be help me.. I don't know.
[21:24] <k0p> it's before debug points.
[21:24] <slayton> do I need to change the rules file to not try to install the libs?
[21:24] <k0p> norsetto, run: strace umit
[21:24] <k0p> and pastebin results, please.
[21:25] <stefanlsd> persia: i went thru each change in the ubuntu* stuff and it looks like they are current. The only thing im not 100% how it happened is the ./configure landing up in the clean target. I moved it to the configure target and its better.
[21:27] <squinky86> persia, NCommander: thank you for your help. That one uploaded correctly.
[21:27] <persia> I suspect ./configure was in clean to make it happen at packaging time rather than build time.  You might check the changelog history for how this came to be.
[21:28] <persia> Also, as this package is in Debian, I discourage updaing the Standards-Version with the merge, even if it happens to be compliant, it's a useless diff.
[21:28] <stefanlsd> persia: by changelog history, you mean the changelog file?  (or is there some other history we can see)
[21:29] <stefanlsd> persia: ok, can fix that...
[21:30] <persia> Yes, the changelog file, but you might have to read quite a lot of it to understand why ./configure might be in clean.
[21:30] <persia> Personally, I think moving it is wise, as in clean seems very odd to me, but it needs understanding or testing or both to be worth modifying.
[21:32] <stefanlsd> persia: will try and find something from the bugs in the changelog.  it doesnt compile with the ./configure in clean.  breaks on looking for X and you get left with a bunch config files. but will look some more...
[21:36] <k0p> norsetto, there're are one way to test what's happen. increase verboisity.
[21:37] <k0p> can you help with it? it's easy. only change a var to True, and run : umit -v -v -v -v -v
[21:37] <persia> stefanlsd: It should compile with it there: it may be that you need more of the build-dependencies installed to build the source.  You might also check with some of the previous uploaders if you get stuck.
[21:37] <norsetto> k0p: which var?
[21:38] <stefanlsd> persia: thanks. will do!
[21:38] <k0p> norsetto, edit /usr/bin/umit line 38
[21:38] <k0p> where False, put True
[21:38] <k0p> norsetto, after editr run: umit -v -v -v -v -v
[21:40] <norsetto> k0p: it says RUNNING WITHOUT PSYCO! and then exit with ImportError: No module named gtk
[21:40] <k0p> grrr
[21:40] <k0p> omg
[21:41] <k0p> pygtk depedencies :X
[21:41] <k0p> norsetto, give me a minutes to fix it ok?
[21:41] <norsetto> k0p: sure
[21:51] <k0p> norsetto, Depends: ${python:Depends}, menu, nmap (>=4.50), python, python (>= 2.5), python-gtk2 | python-pysqlite2, python-gobject
[21:51] <k0p> looks good to dependences?
[21:52] <norsetto> k0p: I thought you needed the python (>= 2.5) | python-pysqlite2 ?
[21:52] <k0p> hmm
[21:53] <nxvl> a motu still need 2 ACK's for new packages or just 1?
[21:54] <jpds> nxvl: Last I read: "They are encouraged to get reviews, but don't need them to upload"
[21:54] <jpds> Not sure if that's changed now.
[21:54] <k0p> norsetto, I'm thinking ... so I'll put python, python-pysqlite2 ok?
[21:54] <geser> nxvl: if it didn't change, motus need only 1 ACK
[21:55] <norsetto> k0p: you better ask somebody that knows about this python stuff, I don't
[21:55] <k0p> k
[21:56] <k0p> ok :)
[21:56] <k0p> RainCT, are you there?
[21:56] <nxvl> geser: thank you
[21:56] <nxvl> :D
[21:57] <geser> k0p: ${python:Depends} will add the dependency on python itself, so you don't need to add it yourself
[21:58] <geser> k0p: and "python, python (>= 2.5)" is redundant anyway
[21:58] <k0p> so remove this words, right?
[21:58] <norsetto> k0p: while you are at it, why don't you add psyco too?
[21:59] <k0p> norsetto, psyco it on Suggests
[21:59] <k0p> it's not mandatory.
[21:59] <norsetto> k0p: I'd rather make it a recommend then
[21:59] <geser> k0p: yes (it's a good idea to check the dependencies of the build deb if they are like you expected)
[21:59] <k0p> sure.
[22:00] <k0p> norsetto, someone around tellme to put psyco on suggests
[22:00] <norsetto> k0p: upstream says "you're encourajed to install it" thats seems stronger than a simple suggest
[22:02] <k0p> hmm
[22:02] <k0p> norsetto, so where you suggest that I add it?
[22:04] <norsetto> k0p: I said it already, as a Recommends instead of as a Suggests
[22:04] <k0p> ok
[22:05] <POX__> psyco works on i386 only, so you have to use: python-psyco [i386 hurd-i386 netbsd-i386 kfreebsd-i386]
[22:05] <k0p> yeap
[22:05] <k0p> sure
[22:06] <persia> nxvl: Generally I consider it to be the case that everyone requires two ACKs, but that MOTU can self-ACK.
[22:06] <nxvl> persia: so MOTU's need 2 ACK's but one of them can be self made?
[22:07] <nxvl> persia: so it's like it gets 1, but on the page there are 2?
[22:07] <persia> nxvl: That's how I interpret it.  Generally, I think the MOTU wants to be their own second ack, so they get Uploaded-By, and direct feedback from archive-admins.
[22:07] <persia> Essentially.
[22:07] <persia> Mind you, and MOTU creating a new package is expected to review their own work...
[22:07] <persia> s/and/any/
[22:08] <nxvl> exactly
[22:08] <nxvl> ok, that make perfect sense to me
[22:08] <nxvl> :D
[22:08] <norsetto> persia: you are the sound buff here around, you know anything about liblo0?
[22:09] <k0p> norsetto, uploading :D
[22:09] <persia> kirkland: Excellent ideas, those.
[22:09] <persia> norsetto: Debugging, or NBS?
[22:10] <norsetto> persia: well, was just wondering if it was worth upgrading
[22:12] <persia> Oh.  Let me look.
[22:16] <k0p> norsetto, http://revu.ubuntuwire.com/details.py?package=umit
[22:16] <k0p> norsetto, can you review now?
[22:17] <persia> norsetto: I don't actually use OSC, but 0.25 seems to have a good set up bugfixes, and upstream moved to liblo.sf.net, which might be interesting to catalog.
[22:19] <norsetto> persia: right, it also seems a good idea to me, I just asked upstream to clarify why he hasn't bumped the soname and version since it seems that there are API/ABI changes.
[22:22] <persia> Probably also want to ping the Debian Maintainer, who seems to have let a couple NMUs go by, and might be interested in an easy update to the latest state post-Lenny.
[22:22] <persia> (it has far too many rdepends to be updated in Debian now)
[22:23] <norsetto> persia: yes, quite a lot of rd and rbd
[22:23] <k0p> norsetto, do you will test?
[22:24] <norsetto> k0p: not today, you can test it yourself on a system which doesn't have gtk stuff installed by default (ie. kubuntu).
[22:25] <k0p> sure.
[22:25] <persia> norsetto: Well, only 22 source packages need an update, but still, that gets painful for 11 architectures (or whatever)
[22:27] <DktrKranz> norsetto, re bug 248150, I'd like to have an exact picture of packages which need love before ACKing it, I'll do some upgrade tests to have things clearer.
[22:28] <norsetto> DktrKranz: be careful because it depends very much on the order of the upgrade
[22:28] <k0p> DktrKranz, can you comment Depends of umit package? only take a look and comment, please.
[22:29] <DktrKranz> norsetto, is there a given order to install packages, or just letting update-manager spawn some magic?
[22:29] <DktrKranz> k0p, I'll have a look
[22:30] <norsetto> DktrKranz: thats the problem, you can't so they may all or none (or something in between) fail
[22:31] <DktrKranz> gah!
[22:35] <norsetto> DktrKranz: to come up with that list, I had to install all the possible packages and to check all their postrm for usage of the R CMD command
[22:36] <DktrKranz> norsetto, "TEST CASE: upgrade... hope to see a crash... check with -proposed version... hope to see none"
[22:37] <norsetto> DktrKranz: no, even if you see none with -proposed it doesn't mean its solved for everybody
[22:37] <DktrKranz> exactly... it's a mess :/
[22:38] <DktrKranz> k0p, done
[22:38] <RainCT> k0p: pong
[22:39] <norsetto> DktrKranz: yes, thats why, since an alternative (not nice,m but working) solution is simply to reconfigure and re-upgrade, I'm more inclined to mark it as won't fix than going to change 32 packages
[22:39] <RainCT> persia: MOTUs need 1 ack from someone else for new packages now? I thought that was recommended, but not mandatory
[22:40] <persia> RainCT: Let's say strongly recommended.  If someone doesn't do that, and the archive admins find a problem, they usually point how the simple facility to get peer review, which can be a bit embarassing.
[22:40] <norsetto> RainCT: its a recommend in the sense that if you don't we kick you out ;-)
[22:41] <persia> Further, in cases where there are questions or contention about an upload, when it didn't go through REVU, some people complain, and typically the person who uploaded it doesn't want that again either.
[22:41] <RainCT> norsetto: heh
[22:41] <DktrKranz> norsetto, I tend to agree with you... it's really ugly, but if there's uncertainty about a fix and how to effectively test it, it's better to provide a workaround (IMHO)
[22:41] <RainCT> Okay, it's like I thought then :)
[22:41] <persia> Anyway, what happened to the nice procedure of sending a note to the mailing list when one uploaded something from REVU?  I liked seeing those.
[22:42] <k0p> RainCT, do you understand about python stuff right?
[22:42] <norsetto> DktrKranz: yes, the workaround is in the bug report, I tested it successfully (twice)
[22:42] <RainCT> k0p: a bit :)
[22:42] <RainCT> (brb)
[22:42] <k0p> RainCT, can you review my package?
[22:44] <k0p> RainCT, when you back, tell please. :)
[22:45]  * NCommander thinks REVU needs a README.quotes file
[22:45] <k0p> lol.
[22:45] <NCommander> Here's probably the best from from dak
[22:45] <NCommander>  <mdz_> SirDibos: that sentence sounds like it wants to be a bug report when it grows up
[22:47] <k0p> :)
[22:47] <zooko> :-)
[22:54] <wgrant> tuxmaniac: Done.
[23:04] <Adri2000> DktrKranz: me once again :p I uploaded to -proposed as well for feisty and dapper (where the patch is slightly modified), bug #243722
[23:04] <james_w> thanks persia
[23:06] <Laney> congrats james_w!
[23:06] <james_w> thanks Laney
[23:06] <james_w> weren't you going to apply this week?
[23:07] <Laney> I was, and still am
[23:07] <Laney> rl took over a little bit though
[23:07] <Laney> maybe tomorrow if I can drum up some sponsors
[23:09] <k0p> DktrKranz, well. I think that now finally the package it's ready.
[23:09] <k0p> but I need to test in a system without gtk
[23:10] <DktrKranz> Adri2000, go go go! :)
[23:12] <Adri2000> DktrKranz: could you add a comment to the bug? as the patch for dapper is not the same
[23:14] <DktrKranz> Adri2000, done
[23:14] <RainCT> k0p: URL?
[23:14] <Adri2000> DktrKranz: thanks!
[23:20] <k0p> RainCT, http://revu.ubuntuwire.com/details.py?package=umit
[23:20] <k0p> :)
[23:22] <k0p> DktrKranz, so.. I didn't fix the changes on copyright. sponsor will fix right?
[23:22] <RainCT> (the problem with REVU where you were forwarded to index.p after login has just been fixed)
[23:22] <k0p> RainCT, I need advocate in package. I make lots of efforts to have umit on intrepid.
[23:23] <DktrKranz> k0p, it's one character fix, I think it's easier to adjust :)
[23:23] <k0p> DktrKranz, yeap I know. But right now I can't fix
[23:23] <k0p> because I lost advocate.
[23:23] <k0p> if RainCT advocate my package I get two advocates. whats happen after?
[23:24] <RainCT> k0p: that I'll upload it :)
[23:24] <k0p> RainCT, upload?
[23:24] <k0p> to packages of ubuntu?
[23:25] <k0p> it's my first package. I don't have experience.
[23:25] <RainCT> btw, I'm looking for someone to review http://revu.ubuntuwire.com/details.py?package=julius. Uhm.. DktrKranz, are you bored? :)
[23:25] <RainCT> k0p: yep
[23:25] <DktrKranz> RainCT, on holiday.... ;)
[23:25] <DktrKranz> I can't be bored :)
[23:26] <huats> james_w: congrats !
[23:26] <huats> TheMuso: are you around ?
[23:26] <k0p> yeap
[23:27] <k0p> james_w, congrats :)
[23:27] <k0p> i see mail in the list
[23:28] <bobbo> congrats james_w!
[23:30] <james_w> thanks all
[23:31]  * beuno cheers james_w
[23:31] <k0p> RainCT, what do you think about my package?
[23:33] <RainCT> james_w: bah, you should already have become u-u-c long time ago...    congrats :)
[23:34] <nhandler> Congrats james_w
[23:44] <RainCT> k0p: I don't recommend using that watch file, as it will break if they change the versioning scheme
[23:45] <k0p> RainCT, I know.
[23:45] <k0p> but there was a trouble with sourceforge.
[23:46] <k0p> DktrKranz suggest this watch file.
[23:47] <ScottK> k0p: There is a specific format in Debian for Sourceforge watch files.  Are you using it (I haven't looked at your package)?
[23:47] <RainCT> ScottK: yes, he is
[23:47] <k0p> ScottK, yeap
[23:48] <ScottK> OK.  That's the one you should be useing then.
[23:48] <k0p> but sourceforge does not works very well in our projects
[23:48] <RainCT> k0p: I see.. Is 6.04.1 older than 0.9.5 or what?
[23:48] <k0p> yeap
[23:48] <k0p> it's older.
[23:49] <k0p> but we already remove this on sf.
[23:49] <k0p> we don't have a option to watch file :/
[23:54] <RainCT> k0p: uhm.. umit seems to be the only application (of those which I have installed) creating a directory in usr/share/icons
[23:54] <RainCT> is that OK?
[23:55] <k0p> RainCT, yeap.
[23:55] <RainCT> as in, is that allowed?
[23:56] <k0p> well I think yes. But I can apply a patch and change it.
[23:57] <k0p> so I'll lost again advocate of DktrKranz. he will shot me :)
[23:57] <RainCT> I think usr/share/icons is only for stuff from themes and such.. but I don't really know
[23:57] <k0p> RainCT, so, what do you advice me?
[23:58] <k0p> RainCT, change it?
[23:58] <RainCT> to wait if someone else answers :P
[23:59] <k0p> RainCT, and you will advocate it?