[01:07] <pjbroad> Hi, may I ask an upload question?
[01:09] <pjbroad> ok, I'll ask anyway.  I uploaded a couple of packages a few weeks ago, I have tried to upload new versions but they never appear, any hints?
[01:10] <Adri2000> upload where?
[01:10] <pjbroad> to http://revu.ubuntuwire.com/uploads.py
[01:11] <pjbroad> nevermind, as if my magic they appeared just now, *slighly sheepishly I'll leave*.....
[01:12] <Adri2000> :)
[01:20] <TomJaeger> Could someone review http://revu.ubuntuwire.com/details.py?package=easystroke ? Thank you.
[04:19] <tbielawa> hello everybody
[05:08] <emma> Hi gnomefreak
[05:09] <gnomefreak> hi emma
[05:45] <dholbach> good morning
[05:46] <ion_> Howdy-ho
[05:46] <Treenaks> morning
[05:46] <nxvl> good morning!
[05:46] <nxvl> dholbach: did you saw jono's mail?
[05:47] <dholbach> nxvl: yes
[05:47] <nxvl> :D
[05:47] <dholbach> I'll get to it later on
[05:47] <dholbach> (lots and lots and lots and lots of stuff to do)
[05:47] <nxvl> take your time
[05:47]  * dholbach hugs nxvl
[05:47] <dholbach> :-)
[05:47]  * nxvl HUGS dholbach back
[05:48] <DBO> oh great a glorious master of the universe... where does one suggest a patch for libgtk2.0-cil?
[05:49] <persia> DBO: In a bug against the gtk-sharp2 package.
[05:49] <dholbach> DBO: https://wiki.ubuntu.com/SponsorshipProcess
[05:50] <DBO> thank you =)
[05:51] <DBO> its a one line patch to fix a memory leak that was already committed into GTK-sharp trunk... do i need to go through that whole process dholbach?
[05:53] <RAOF> DBO: The bug filing is not optional
[05:53] <persia> DBO: Well, someone has to commit the fix and upload it.  If you want to do most of the work, it makes it easier for others.  If you don't have time, someone else may read the bug.
[05:53] <RAOF> DBO: But you could just dump the patch on the bug if you want.
[05:54] <RAOF> Well, I suppose the bug filing _is_ optional, really.  I've got a stake in the outcome and might eventually find time to hunt this down without a bug.
[05:55] <DBO> its just in the Gtk.Metadata file...
[05:56] <DBO> RAOF, that change
[05:56] <DBO> http://anonsvn.mono-project.com/viewcvs/trunk/gtk-sharp/gtk/Gtk.metadata?rev=109594&view=auto
[05:57] <DBO> here is the diff
[05:57] <DBO> http://anonsvn.mono-project.com/viewcvs/trunk/gtk-sharp/gtk/Gtk.metadata?rev=109594&r1=107494&r2=109594
[05:57] <RAOF> DBO: Put that on a LP bug please.  You can assign it to me if you want.
[05:58] <DBO> can do boss
[05:58] <DBO> whats your LP name?
[05:58] <RAOF> raof
[05:58] <RAOF> Nice and simple.
[05:59]  * RAOF is fond of this nick.  He hasn't come across a nick collision yet.
[06:00] <DBO> okay
[06:00] <DBO> done
[06:01] <persia> DBO: What's the bug number?
[06:01] <DBO> https://bugs.launchpad.net/ubuntu/+source/gtk-sharp2/+bug/254855
[06:02] <DBO> basically Gtk# leaks every pixbuf you load from your icon theme.  It just so happens you wont notice this unless you do this an aweful lot.   GNOME Do does this, and thus can leak an aweful lot of memory
[06:24] <Gustov> hey guys, will updating via disk destroy my linux?
[06:25] <Gustov> I'm on fiesty fawn
[06:26] <persia> Gustov: Depends on how you upgrade.  You may want to ask for advice on the upgrade path in #ubuntu
[06:30] <Gustov> I was hoping usb
[06:30] <Gustov> the prob. is I can't get internet
[06:31] <persia> Gustov: One can upgrade with no internet access.  On the other hand, you may need support to do so, which is why I suggest #ubuntu: our support channel.
[06:32] <Gustov> okay, thanks
[06:48] <nxvl> time to sleep now
[06:48] <nxvl> read you later!
[06:48] <coppro> does anyone have experience with KHotKeys breaking in 4.1?
[07:40] <slytherin> Can someone please give back libjboss-cache1-java?
[07:41] <persia> slytherin: On i386?
[07:41] <persia> slytherin: given-back
[07:41] <slytherin> persia: yes
[07:44]  * TheMuso likes being able to retry builds rather than having to ask an admin to do it.
[07:45] <persia> TheMuso: Well, we still have an ask-an-admin model, but there are now >100 admins, rather than just 4 :)
[07:45] <TheMuso> persia: True.
[07:45]  * persia waits for wider sync privileges
[07:45] <TheMuso> Is that coming?
[07:46] <persia> I hope so.
[07:46] <Hobbsee> supposedly.
[07:46] <persia> Currently, I can fake it fairly well, so it looks like I did a sync, but many people make mistakes doing that.  A LP UI would be an improvement.
[07:46]  * persia had to sync a few packages manually in hardy, as the automated tool couldn't
[07:47] <RAOF> I seem to recall the LP people bemoaning the fact that a bunch of archive tasks are achieved by running scripts on the datacentre.
[07:47] <Hobbsee> yeah, they are.
[07:48] <persia> RAOF: RIght.  It's a matter of getting the tools from somewhat kludgy scripts into Soyuz, and then exposing a UI.
[07:51] <siretart> saivann_: feel free to upload both gnucash 2.2.6 and libaqbanking 3.5 to gnucash PPA, both hardy and intrepid
[07:51] <siretart> details in my email
[07:53] <Hobbsee> persia: and them reliably working, yes.
[07:53] <Hobbsee> persia: there's not really a lot of demand for it, though
[07:53] <persia> Hobbsee: How is the demand measured?  I could be demanding.
[07:54] <siretart> https://blueprints.edge.launchpad.net/soyuz/2.1 shows the next features for soyuz
[07:54] <siretart> persia: I have been sent another list of soyuz specs where we are asked to prioritize
[07:54] <siretart> persia: very similar to the specs for malone, but way shorter
[07:55] <persia> siretart: I'm happy to share feedback if you like.
[07:55] <StevenK> siretart: I doubt it, most of them are Implemented
[07:55] <persia> Anyway, https://blueprints.edge.launchpad.net/soyuz/+spec/sync-workflows is on the 2.1 list, and the one I was talking about just now.
[07:55] <siretart> persia: did you already respond to my call for help in prioritizing the specs?
[07:56] <persia> siretart: Not formally: I'm not in either of the groups you asked for feedback.  Do you want commentary and prioritisation for the entire list?
[07:56] <Hobbsee> persia: oh yes, you work for canonical now.  but there aren't a lot of archive admins, or canonical people pushing them.
[07:56] <siretart> persia: I see you did already comment on 2 specs, but a general prioritisation would be exactly what the launchpad crew has asked us to do
[07:57] <persia> Hobbsee: That canonical is one of my clients doesn't necessarily mean I have any more or less influence than I have anyway.
[07:57] <siretart> persia: oh, you got hired by canonical?
[07:57] <Hobbsee> persia: OTOH, MOTU pushes many bugs that they want fixed, so it probably gets lost in the noise.
[07:58] <persia> siretart: The easiest thing would be to say "Yes", although it's more complicated than that.
[07:58] <siretart> persia: well, then I will say an easy 'congrats'! :-)
[07:58] <siretart> persia: may I ask what you are going to work on?
[08:00] <RAOF> persia: Cool!  Congrats.
[08:00] <persia> siretart: Yes, but I can't answer.  Mobile stuff is part of it.
[08:00] <persia> Anyway, back to the point.
[08:00] <siretart> ah, that's enough for me :-)
[08:00] <persia> siretart: So, should everyone provide feedback and prioritisation to the list of specs?
[08:01] <siretart> persia: I asked every member of the release and SRU team for that, yes
[08:01] <persia> siretart: Right.  I'm not on those teams, and you've just asked me, which is why I'm confused :)
[08:03] <persia> I have opinions, but don't want to add noise to your workflow.
[08:03] <siretart> oh right, you're motu-council. Does motu-council work a lot with bugs?
[08:03] <siretart> persia: no, the feedback is quite low, I'm happy with any response
[08:03] <persia> Not in their role as MOTU Council.  Mind you, each of the members does.
[08:04] <persia> siretart: I'll dig up the email again and number them 1 through 15 then.  If you're looking for more feedback, I'd also encourage you to add to the thread that you'd like more feedback from other interested MOTU.
[08:05] <persia> Personally, I think Hobbsee and wgrant are fairly active in LP-watching, and likely have opinions, although I think neither is currently a member of either of the targeted groups.  There are likely also other interested people.
[08:05] <siretart> persia: the thing is that I'm going to leave on VAC for 2 weeks starting on tomorrow. I need to make an interim report and hand the task over to sistpoty, I think (he doesn't know about that yet, though ;)
[08:05] <persia> Well, he does now :)
[08:05]  * StevenK was just about to say that
[08:05] <Hobbsee> i'm still thinking on what stuff i'd like to prioritise.
[08:05] <Hobbsee> i'll have to respond to it tomorrow
[08:05] <siretart> he's not around, I need to call him on the phone this afternoon
[08:05] <persia> siretart: I'll get it to soonish then.
[08:06] <siretart> persia: Hobbsee: thanks!
[08:06] <persia> s/it to/to it/
[08:06] <Hobbsee> siretart: poke me if i haven't done it in 24h ?
[08:07] <StevenK> Hobbsee: You may not have 24h :-)
[08:07] <Hobbsee> i don't expect to need it.  i'm just not about to do it at uni
[08:07] <BUGabundo_work> good morning!
[08:09] <siretart> Hobbsee: ok
[08:09] <Hobbsee> heck, i can't even sign into LP here.
[09:16] <TomJaeger> I have a question about the process of getting a package into intrepid:  Should I, in addition to posting the package on REVU, also file a launchpad bug report (or maybe have someone file it for me)?
[09:20] <huats> morning everyone
[09:31] <TomJaeger> so should I file a bug report or not?
[09:31] <BUGabundo_work> TomJaeger: from what I've read on ML, yes you should
[09:32] <BUGabundo_work> and assign it to the person or team in charge of that package
[09:32] <TomJaeger> okay, thanks.
[09:38] <stefanlsd> warp10: u around?
[09:41] <persia> TomJaeger: You'll want to assign yourself if you are packaging it for REVU.
[09:41] <warp10> stefanlsd: here!
[09:41] <persia> BUGabundo_work: Generally, you shouldn't assign anyone else a bug unless you know for certain they want it assigned to them.
[09:42] <TomJaeger> okay, I'll assign it to myself
[09:43] <stefanlsd> warp10: aah cool. i just wanted to ask about the watch file i did for mp3wrap and the submission to debian. you posted that - 'Just noticed you didn't add the tag to autoclose the bug in debian/changelog.'  Just wanna understand how i should of done it so i can make sure i do it properly next time...
[09:45] <warp10> stefanlsd: It's easy: in debian/changelog if you add something like (LP: #XXXXXX), where XXXXXX is the bug number, the bug is autoclosed when the package is uploaded into archives
[09:47] <stefanlsd> warp10: oh ok. didnt realise that. So i should of put the bug itself in the changelog with the LP: # i was closing by the submission.   makes sense. thanks.
[09:48] <warp10> stefanlsd: exactely. You can put the tag wherever you want. Usually it is at the end of the line explaining the change you made that fixes that bug, and you can even add more than one, in case the changelog closes several bugs.
[09:57] <TomJaeger> done ( https://bugs.launchpad.net/ubuntu/+bug/254893 )
[10:01] <james_w> who would like to make dholbach a very happy man? http://revu.ubuntuwire.com/details.py?package=python-wadllib http://revu.ubuntuwire.com/details.py?package=python-launchpadlib
[10:03] <persia> james_w: Perhaps not using "edge" in the homepage?  Anyway, my python packaging isn't good enough for a proper review.
[10:04] <james_w> persia: ah, thanks
[10:05] <persia> Also seems a bit odd to demand debhelper 7, and use a debhelper 5 style rules file.
[10:07] <RAOF> dh $@ ftw :)
[10:07] <persia> Well, unless one wants to support backports, in which case debian/compat of 7 is a bit agressive.
[10:07] <RAOF> Right.
[10:08] <RAOF> What, you mean we support releases older than Intrepid? :)
[10:08] <persia> Given the specific libraries, and my personal opinions as to the reasons for the packaging, supporting backporting seems a reasonable goal.
[10:08] <RAOF> Yes, certainly.
[10:09]  * wgrant expects it will need to be SRUed heavily.
[10:09] <persia> wgrant: SRUed?  Why?
[10:09] <persia> I'd think SRUing ports of all the rdepends would be a bit of a stretch from the no-new-features-in-SRU guidelines.
[10:11] <wgrant> persia: Better than breaking every time LP feels like it needs to change something.
[10:11] <persia> wgrant: I guess.  Are we certain that this isn't going to change as often?
[10:12] <RAOF> james_w: You appear to have set Vcs-Bzr to a branch only you will have commit access to.  This seems anti-social :)
[10:12] <wgrant> persia: It is labeled beta.
[10:12] <persia> s/seems/is/
[10:12] <james_w> RAOF: it's bzr, you can have commit access to your own branch :-)
[10:12] <persia> wgrant: Depends on the definition of "beta" then.
[10:12] <persia> james_w: Yes, but packaging can't be coordinated safely with the variance.
[10:12] <RAOF> james_w: Given you've listed me as a maintainer, I'd hope to have write access to the cannonical trunk :)
[10:13] <wgrant> persia: It has 'beta' in the REST URLs it uses, IIRC.
[10:13] <james_w> RAOF: if I do that then I don't get commit access
[10:13] <james_w> persia: I'm not sure I understand
[10:13] <persia> james_w: Well, you could put it somewhere to which both of you have access.
[10:14] <persia> james_w: OK.  I branch your packaging branch.  I change it.  I upload.  RAOF wants to make changes.  From where does he pull?
[10:14] <wgrant> Or put it somewhere where the people with upload rights have access and can merge from unprivileged branches, which makes a whole lot more sense.
[10:14] <persia> Does each person changing need to mangle the Vcs-* headers?
[10:14] <RAOF> I'm not sure that's a problem, though.  MOTU will be maintaining it, motu should definitely have commit access, and I don't think !motu should have commit access.
[10:14] <wgrant> RAOF: Right.
[10:15] <persia> Well, I can see the case for allowing certain !motu commit access to certain packages, but generally that makes sense.
[10:15] <RAOF> Right.  Until we have a debian-maintainer style permission system, I think keeping commit rights equivalent to upload rights is not unreasonable.
[10:15] <wgrant> persia: Why shouldn't package branches have the same permissions as the package itself?
[10:16] <wgrant> RAOF: We do.
[10:16] <wgrant> RAOF: It is only used for one package, AFAIK.
[10:16] <RAOF> Oh, wow?  Which one?
[10:16] <persia> wgrant: Well, it's not always done that way in Debian.  I suppose part of that might be differences in workflow between SVN and BZR.
[10:16] <wgrant> dkms
[10:16] <RAOF> And why aren't we using this more?
[10:16] <wgrant> RAOF: Soyuz only got it recently.
[10:16] <persia> RAOF: Because it requires TB approval for each case, and manual adjustment by LP admins.
[10:16] <wgrant> RAOF: And I don't think its use has been authorised by the RB.
[10:17] <wgrant> *TB
[10:17] <persia> Once the UI gets cleaner, we ought be using it more.
[10:17] <wgrant> And there's no UI for it, right.
[10:17] <RAOF> Ah.  So it's not finished enough to really use.  Check.
[10:19] <persia> Nice thing about the implementation is that it's inclusive: rather than being that some person can upload, it's that some person can *also* upload.
[10:20] <huats> hello persia
[10:20] <huats> how are you ?
[10:20] <huats> TheMuso: are you around ?
[10:20] <persia> huats: OK.  It's less hot here because of the storm.
[10:20] <Koon> persia/wgrant: what would be the process james_w should follow ? Change Vcs-Bzr before submitting it to REVU ? At that point he still needs to commit changes...
[10:20] <huats> hum...
[10:20] <huats> you are lucky :)
[10:20] <huats> it is way too hot in here...
[10:21] <persia> Koon: There's no good model that has been established to permit accurate Vcs-* in REVU packages by non-MOTU.
[10:22] <RAOF> I'd suggest setting Vcs-Bzr to the value it should be once the package is in the archives.  The uploader should also push the corresponding bzr branch.
[10:22] <persia> RAOF: But will the uploader?  It may be that that doesn't happen.
[10:23] <RAOF> Man, wouldn't NoMoreSourcePackages be useful here...
[10:23] <Koon> RAOF: I would suggest setting it to the developer branch, and if the uploader thinks about it, change it when he pushes the branch somewhere else
[10:23] <persia> Koon: But that makes "Maintainer" inaccurate by default.
[10:24] <persia> Mind you, in most cases, Vcs-* is inaccurate and potentially harmful in Ubuntu anyway, so perhaps it doesn't matter much.
[10:25] <dholbach> nxvl: http://daniel.holba.ch/blog/?p=146
[10:25] <dholbach> nxvl: excellent work! :)
[10:25] <persia> RAOF: NoMoreSourcePackages wouldn't necessarily solve this: while there might be a facility to preserve history (or possibly not, depending on how the uploader uploaded), james_w would still not be able to commit to the branch that contained correct information, and someone would need to manually adjust things.
[10:26] <Koon> persia: with RAOF suggestion it's Vcs-Bzr which is inaccurate by default :) it's kind of chicken-and-egg anyway. the only way to be accurate is to remove it (accurate by omission)
[10:26] <persia> Koon: Precisely.  If later the maintainer wishes to use a VCS, it can be added.
[10:26] <james_w> persia: but the sponsor would be using bzr, whereas that's not guaranteed now
[10:27] <persia> james_w: That's not guaranteed with NoMoreSourcePackages either, or at least from the last rumours I heard.
[10:27] <persia> Something about supporting the dput use case?
[10:27] <wgrant> Doesn't that violate the basic principle of NMSP?
[10:27] <james_w> persia: if there are NoMoreSourcePackages then you can't dput anything
[10:27] <wgrant> dput is going away soon for other reasons, anyway.
[10:28] <persia> james_w: Ah.  I heard talk about having an autocommit of changes on dput
[10:28] <persia> wgrant: What reasons would those be?
[10:28] <wgrant> persia: Well, at least for PPAs SFTP will apparently be supported. It will allow things like removing .changes replay vulnerabilities, and allowing upload-time feedback on whether an upload failed or not.
[10:29] <james_w> persia: yes, but that's not NMSP. NMSP is somewhere that we might go, but it's not the starting point. Initially there will be the autocommit  on dput
[10:29] <persia> wgrant: No reason dput can't do sftp.
[10:29] <wgrant> persia: True.
[10:29] <persia> james_w: See, if that gets enabled, disabling it becomes interesting.
[10:29] <james_w> persia: yep
[10:29] <persia> On the other hand, if that doesn't get enabled, bootstrapping problems ensure.
[10:30] <persia> s/ensure/ensue/
[10:30] <persia> As a result, I imagine dput support (possibly over sftp) would remain for a while.
[10:30] <persia> Although, I suspect people are more careful with GPG keys than SSH keys, so think that's not a positive step, entirely.
[10:31] <wgrant> The .changes replay hole needs to be fixed.
[10:31] <persia> That is one of many issues.
[10:32] <persia> Personally, I think the "target distribution" is the way to solve that: use e.g. "intrepid-persia" for my PPA.
[10:32] <persia> That way it fails if I push it somewhere else.
[10:32] <wgrant> Indeed, that would make sense.
[10:33] <wgrant> And stop people from shooting themselves in the foot, too.
[10:33] <persia> That also conveniently breaks pocket-copies from PPA to archive, which I suspect are inherently unsafe for other reasons.
[10:33] <persia> (e.g. unexpected dependencies, etc.)
[10:33] <wgrant> Particularly with the lack of ogre-model
[10:34] <persia> Well, that, and the ability to depend on other PPAs which may or may not have wholly new packages.
[10:34] <persia> (which is external to the control of the PPA concerned)
[10:59] <devfil> Adri2000: ping
[13:09] <Adri2000> devfil: pong
[13:10] <joaopinto> Hello
[13:10] <devfil> Adri2000: I've reply at the bug for the merge of amsn, can you take a look at it?
[13:10] <joaopinto> could some review http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
[13:11] <Adri2000> devfil: yep
[13:14] <Adri2000> devfil: I don't think amsn should depend on both tk8.5 and tk8.4
[13:14] <Adri2000> and upstream confirmed me it should work just fine with tk8.5
[13:14] <Adri2000> fix for kde4 thing: ok
[13:15] <Adri2000> makefile patch: if you choose to drop that ubuntu change, you should mention it in the changelog
[13:16] <Adri2000> I agree that this change isn't really useful, it just sounds more logicial to do that way. but if we want to reduce the delta with debian, let's drop it
[13:18] <Adri2000> devfil: got my comments?
[13:18] <devfil> Adri2000, no
[13:20] <persia> Unless the change still accomplishes something useful (fixes a bug), it's better to reduce delta.  If a bug exists without the change, let's keep the delta.
[13:22] <Adri2000> persia: the change is just about moving some clean commands from debian/rules to the upstream Makefile (where they really should be)
[13:23] <Adri2000> devfil: I'll put them in the bug report
[13:23] <persia> Adri2000: Yeah, I don't think it's worth keeping that.  The commands are still in diff.gz
[13:25] <devfil> Adri2000, why we should continue to make hard the next merges? the makefile problem seems to be only an esthetical choice
[13:25] <devfil> we should drop useless changes like this
[13:26] <Adri2000> devfil: yes, that's what I was saying, see the bug report
[13:26] <Adri2000> you should just mention that you dropped the change in the changelog
[13:27] <Adri2000> and anyway the patch is going upstream (I just told them about it)
[13:34] <devfil> Adri2000: done
[13:41] <Adri2000> devfil: you don't mention in the changelog the ubuntu changes you are dropping
[13:41] <devfil> Adri2000: is it a
[13:41] <devfil> "must"?
[13:41] <Adri2000> I don't know, at least I think it's better
[13:42] <Adri2000> also, how is the debian/amsn.desktop removal a useful change to keep?
[13:42] <devfil> Adri2000: when you use grab-merge.sh to do a merge and you have a conflict and the best solution is from debian you mention that you have choice debian solution?
[13:43] <StevenK> devfil: I would just mention that the Ubuntu change is dropped in the changelog.
[13:43] <StevenK> devfil: Rationale isn't needed so much
[13:43] <devfil> Adri2000: It isn't installed, but also messenger.xpm is useless, maybe the best solution is to report this to debian and for now to don't drop them
[13:44] <Laney> Afternoon all. Anyone up for a review of http://revu.ubuntuwire.com/details.py?package=goocanvasmm ? :>
[13:44] <Adri2000> devfil: I think so yes
[13:45] <Adri2000> devfil: how is bug #249534 fixed by your merge?
[13:45] <devfil> Adri2000: the new version fixes the problem
[13:46] <devfil> it is a problem of the new windows servers
[13:46] <Adri2000> no
[13:46] <Adri2000> the bug is about a tls module
[13:46] <Adri2000> not about not being able to connect
[13:47] <Adri2000> the not being able to connect is bug #243722
[13:47] <Adri2000> which is indeed fixed in amsn >= 0.97.1
[13:48] <devfil> Adri2000: the tls problem is fixed in the new version, I'm sure about this, but if you don't I can ask the user to try the new version and then to mark the bug as fixed
[13:49] <Adri2000> devfil: can you reproduce the tls bug with the current 0.97 package?
[13:49] <devfil> Adri2000: let me try
[13:53] <devfil> Adri2000: not needed to test, it is already tested in the 0ubuntu6 package (thanks to DktrKranz)
[13:53] <devfil> s/tested/fixed/
[13:54] <sistpoty|work> hi folks
[13:55] <geser> Hi sistpoty|work
[13:55] <sistpoty|work> hi geser
[13:56] <Adri2000> devfil: if you're sure that upload fixes this bug, then close it manually explaining why it is fixed, but do not close it in your unrelated merge
[13:56] <Adri2000> hi sistpoty|work :)
[13:56] <sistpoty|work> hi Adri2000
[13:57] <devfil> Adri2000: done
[13:58] <Adri2000> devfil: also I'd suggest adding a new line in the changelog saying the new upstream release fixes the connection bug (LP: #243722), because with the current "merge .. (LP: #...)" it seems to me these are all merge bugs
[13:59] <devfil> Adri2000: next time, can you please explain me all the changes before? so I don't need to do a lot of debdiff, thanks
[14:01] <Adri2000> devfil: wait until I tell you it's ok to upload your debdiff, but I think it's good to do such live reviews :)
[14:02] <devfil> Adri2000: done, there are other changes that
[14:02] <devfil> I should do?
[14:02] <bddebian> Heya gang
[14:02] <Adri2000> devfil: have you listed the dropped ubuntu changes?
[14:02] <Adri2000> bddebian: heya bddebian !
[14:02] <persia> bddebian: Hey.  NBS needs *you* :)
[14:02] <devfil> Adri2000: yes
[14:03] <Adri2000> devfil: cool, let me do a final check and I think we are done
[14:03] <sistpoty|work> hi bddebian
[14:05] <bddebian> Heya Adri2000, persia, sistpoty|work
[14:05] <bddebian> persia: NBS?
[14:06] <persia> bddebian: http://people.ubuntu.com/~ubuntu-archive/NBS/ : I'm just remembering some of your package upload marathons, and thought I could tempt you: if you've forgotten, no worries.
[14:08] <nxvl> dholbach: \o/
[14:08] <nxvl> dholbach: awesome
[14:08] <dholbach> :-)
[14:10] <Adri2000> devfil: please upload, that should ok
[14:10] <devfil> Adri2000: ehm... what?
[14:11] <Adri2000> s/upload/attach your debdiff to the bug/
[14:11] <devfil> Adri2000: done
[14:12] <devfil> I've already uploaded it
[14:12] <Adri2000> thanks
[14:12] <bddebian> Ah NBS as in Not Build from Source?
[14:13] <bddebian> built even
[14:13] <persia> bddebian: Yep.
[14:13]  * persia hunts the wiki
[14:15] <persia> https://wiki.ubuntu.com/UbuntuDevelopment/NBS seems to be a reasonable summary.
[14:15] <Adri2000> devfil: FYI I'm updating the package to 0.97.2, so there will be your merge and the new upstream release in the same upload
[14:15] <Kopfgeldjaeger> How can I remove a folder in debian/myapp when using cdbs [so that it's not in the binary package]?
[14:16] <devfil> Adri2000: so why you don't have done the merge?
[14:17] <joaopinto> Kopfgeldjaeger, I believe you can use the install/package:: rule
[14:17] <Kopfgeldjaeger> ok, thank you
[14:18] <joaopinto> I am not just sure wether it's called before or after the CDBS dh_install, but I believe it's before
[14:18] <bddebian> persia: I'll see what I can do
[14:18] <slytherin> Kopfgeldjaeger: do not include it in debian/myapp.install file.
[14:18] <persia> bddebian: It's up to you: if you're busy with other stuff, that's well understandable.
[14:19] <Kopfgeldjaeger> slytherin: i don't do that anyway
[14:19] <Adri2000> devfil: I could. but you had already put a debdiff in LP, and we try to not duplicate efforts. so I review what you've done and use it.
[14:19] <slytherin> Kopfgeldjaeger: then I think the folder won't end up ni .deb
[14:19] <persia> Kopfgeldjaeger: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2480675 is likely what you seek.
[14:20] <Kopfgeldjaeger> it works, thank you
[14:20] <bddebian> persia: You know me, I don't do anything :)
[14:21] <persia> bddebian: Which is precisely why I thought you'd like NBS: it's uploading things without actually changing them: the very definition of not doing anything :)
[14:25] <bddebian> heh
[14:31] <Adri2000> devfil: there is a duplicated patch
[14:32] <devfil> Adri2000: ?
[14:32] <Adri2000> debian/patches/04_settingoff_autoupdate.dpatch
[14:32] <Adri2000> debian/patches/05-disable_newVersionCheck.dpatch
[14:32] <Adri2000> the first one was added by the debian maintainer
[14:33] <Adri2000> it seems he sometimes forgets to add things to the changelog
[14:33] <Adri2000> so I agree it's not easy for us...
[14:33] <devfil> Adri2000: are you sure that they are the same?
[14:33] <Adri2000> err no you're right
[14:34] <Adri2000> ok, forget what I said :)
[14:34] <devfil> Adri2000: I'm not a stupid, maybe I can be wrong but I usually do a testbuild for each debdiff ;)
[14:36] <persia> devfil: Mistakes are not about intelligence: they are just a result of being human :)  In this case, it's not yours, but next time it might be...
[14:36] <sistpoty|work> geser: you're uploading crack :P
[14:49] <slytherin> geser: FYI ... I am already working on libjboss-cache1-java FTBFS. So don't put your time on fixing it.
[14:52] <geser> slytherin: it still FTBFS? I didn't have time to look at it
[14:54] <slytherin> geser: yes, due to aop classes. We need to bypass then. But there is another problem. The jar file in resultant .deb has no class files.
[14:55] <slytherin> geser: forget the second part. It was my mistake.
[15:01] <persia> slytherin: It failed again after the rebuild?
[15:08] <slytherin> persia: yes
[15:08] <persia> :(
[15:31] <kirkland> I uploaded a package (musica) to REVU, but I don't see it on http://revu.ubuntuwire.com/index.py
[15:31] <kirkland> the upload looks to have succeeded
[15:32] <kirkland> and trying to upload again yields "already uploaded"
[15:33] <james_w> kirkland: the "already uploaded" is a dput safety mechanism, you can override it if you need to
[15:33] <james_w> kirkland: did you log in to REVU first?
[15:33] <kirkland> james_w: i have not.... logging in now....
[15:34] <james_w> that will import your GPG key from launchpad, which should mean that your upload will be recognised next time
[15:34] <persia> kirkland: Remember to delete your .upload file locally.
[15:34] <james_w> if you already had an account then I believe you can merge them
[15:35] <kirkland> james_w: i have uploaded to revu before
[15:35] <kirkland> james_w: this one seems to be misbehaving
[15:36] <LucidFox> If the upstream software is GPL, can the packaging be BSD?
[15:36] <persia> kirkland: There was recently a change in keyring management that reset the keyring.
[15:36] <persia> LucidFox: Yes, but that's a bit odd.  The resulting package is GPL.  Be cautious of the advertising clause.
[15:37] <kirkland> okay, i deleted my upload file, and dput to revu again
[15:38] <kirkland> and I logged in
[15:38] <persia> And now wait 5 minutes :)
[15:38] <LucidFox> the packager specifically said revised, so no advertising clause
[15:40] <tuxmaniac> dholbach: pm?
[15:41] <dholbach> tuxmaniac: sure
[15:52] <persia> kirkland: Your package is there?
[15:52] <kirkland> persia: yep, just showed up ;-)
[15:52] <persia> Excellent :)
[15:52] <kirkland> persia: see musica
[15:52] <james_w> http://revu.ubuntuwire.com/revu1-incoming/musica-0808051650/lintian
[15:53] <james_w> the last one is probably a mistake?
[15:53] <james_w> it would be great to fix the second.
[15:53] <kirkland> james_w: i can fix the first 2
[15:54] <james_w> rockin'
[15:54] <persia> kirkland: Not the third?
[15:55] <kirkland> persia: i'm not sure I understand the 3rd warning
[15:55] <james_w> kirkland: if this isn't meant to be a native package then you didn't have a correctly named .orig.tar.gz in the parent directory while building the source package
[15:55] <persia> kirkland: Essentially, it couldn't find the orig.tar.gz when you built the source pacakge.
[15:55] <james_w> if it is meant to be native there should be no "-" in the version number
[15:56] <james_w> the .tar.gz has to be precisely named: musica_0.1.orig.tar.gz
[16:39] <Kopfgeldjaeger> If I don't want a (AUTHORS)-file to be included in my binary package [I do not include it anywhere myself, but cdbs does], should I just remove it in install/myapp:: ?
[16:42] <slytherin> geser: persia: The build failure for libjboss-cache1-java is a mess. I feel like chasing a car at 100mph on a bicycle. :-(
[16:45] <geser> slytherin: how got the DD then got it build?
[16:45] <slytherin> geser: That is a question I keep asking to myself again and again. :-)
[16:46] <slytherin> geser: probably they didn't and they will realize the mess once there is a rebuild for those packages
[16:48] <slytherin> geser: I will try updating that package to latest upstream version sometime this weekend. Let's what happens.
[16:50] <LucidFox> lol :)
[16:50] <LucidFox> avidemux (1:2.4.3-0.0) unstable; urgency=low
[16:50] <LucidFox>   * New upstream release.
[16:50] <LucidFox>   * Move to cmake (I still hate cmake).
[17:18] <Kopfgeldjaeger> How many characters per line are 'allowed' in a man page?
[17:20] <sebner> Kopfgeldjaeger: as usual 80 I suppose
[17:20] <Kopfgeldjaeger> OK. Thanks.
[17:21] <sistpoty|work> Kopfgeldjaeger: man pages wrap automatically, so there isn't really a strong limit to 80 chars
[17:21] <sebner> huhu sistpoty|work btw ^^
[17:21] <sistpoty|work> hi sebner
[17:22] <Kopfgeldjaeger> so I should just write a long text passage in one line (if it doesn't have, say, 10k chars)?
[17:22] <Kopfgeldjaeger> 'long' does mean <150 chars for my purposes
[17:22] <sistpoty|work> Kopfgeldjaeger: sure, whatever suits you
[17:23] <sistpoty|work> Kopfgeldjaeger: personally, I don't exceed 80 chars anywhere, but that's because I know that I can get 3 vsplits with 80 chars each on my desktop :)
[17:33] <slytherin> geser: Now that libpdfbox-java is fixed, IIRC jabref is a sync now and not a merge.
[17:40] <nxvl> Adri2000: i don;t understand your amsn versioning
[17:40] <nxvl> Adri2000: why did you have ~debian0 instead of just -0?
[17:41]  * sistpoty|work heads home... cya
[17:42] <Adri2000> nxvl: it's not ~debian0 it's ~debian-0
[17:43] <Adri2000> as saif in the changelog, I kept the versioning scheme used in debian
[17:43] <Adri2000> said*
[17:43] <Adri2000> that is, adding ~debian to the upstream part
[17:43] <Adri2000> I guess the debian maintainer does that because the upstream tarball is changed
[17:45] <nxvl> sounds fair
[17:45] <nxvl> Adri2000: thank you for clarification :D
[17:45] <Adri2000> np
[17:48] <Adri2000> do I need an ack from the sru team to upload to -proposed?
[17:50] <nxvl> i think you can upload to proposed, and then you need and ACK to move it tu -updates
[17:52] <Adri2000> I don't see any ack needed in https://wiki.ubuntu.com/StableReleaseUpdates, but https://wiki.ubuntu.com/ArchiveAdministration#head-1f27dc12ab1558ec21b31ac44e4c86a87a4cd053 says that archive admins should "#
[17:52] <Adri2000> #
[17:52] <Adri2000> Only process an upload if the SRU team approved the update in the bug report trail.
[17:52] <Adri2000> "
[17:52] <Adri2000> (bad wiki copy/paste)
[17:59] <geser> Adri2000: you need an ack to get the package accepted into -proposed
[17:59] <geser> I guess the archive admins will reject an upload without an ACK
[18:05] <Adri2000> geser: ok, that's not very clear from the wiki page
[18:07] <geser> Adri2000: at least that's the way I do SRUs
[18:12] <huats> norsetto: my old friend !!
[18:15] <norsetto> huats: old ?
[18:15] <huats> friend for a long time :)
[18:15] <norsetto> huats: my young and slim friend :-)!!
[18:16] <huats> LOL
[18:16] <huats> slim ?
[18:16] <huats> ;)
[18:16] <huats> not yet
[18:16] <norsetto> huats: hmmm, Geraldine parents hit again?
[18:17] <huats> nope
[18:17] <huats> but a WE in amsterdam :)
[18:17] <norsetto> huats: ahhh, that will definetively help your diet!
[18:19] <sebner> norsetto: because of the snow? ^^
[18:20] <norsetto> sebner: snow? Is that an Austrian name for, hmmm, spacecake?
[18:24] <sebner> norsetto: I thought everybody understands :P
[18:25] <emgent> norsetto: o/
[18:26] <k0p> DktrKranz, are you there?
[18:27] <norsetto> emgent: o/
[18:27] <sebner> emgent: \o/
[18:27] <emgent> sebner: hey hey hey
[18:31]  * NCommander is sad
[18:31] <NCommander> my laptop died, and now I'm stuck in a win32 world
[18:31] <norsetto> NCommander: think that you could be stuck in a win64 world
[18:31] <Treenaks> or a macworld
[18:31] <NCommander> norsetto: I'm debating creating Ubuntu for win32 ...
[18:32]  * NCommander is not kidding either
[18:32] <Treenaks> NCommander: you mean wubi?
[18:32] <NCommander> No
[18:32] <NCommander> I mean native dpkg/apt/etc.
[18:32] <Treenaks> NCommander: eek
[18:32] <NCommander> ;-)
[18:32] <NCommander> there was some work extended Debian in this direction
[18:34]  * norsetto doesn't think he would like a wubuntu
[18:34] <NCommander> how about a Darubuntu?
[18:34] <NCommander> (Ubuntu userland on Darwin/OSX)
[18:35] <norsetto> NCommander: dubuntu (sic) is probably more appropriate
[18:36]  * NCommander admits a passing interest in working in that
[18:36] <NCommander> The trick is building Darwin x86/powerpc from source
[18:36] <emgent> i know emerde.
[18:36] <emgent> and fink
[18:37] <azeem_> emerde?
[18:37] <NCommander> well, Darwin is already based around a packaging building system, and GNOME and KDE already ahve upstream patches
[18:37] <azeem_> sounds french
[18:37] <NCommander> Might be an interesting project to work on
[18:37] <emgent> nah sounds italian :)
[18:37] <NCommander> Install wmaker, and you have the closest to a opensource OPENSTEP your going to get
[18:37] <emgent> http://emerde.freaknet.org/
[18:38]  * NCommander misses NeXTstep
[18:39] <norsetto> emgent: never ask a finnish how they say "Look at the sea"
[18:40] <NCommander> emgent: interested in Darwin-based Ubuntu? ;-)
[18:41] <NCommander> (and if your still interested in a wmaker based Ubuntu emgent there is an easy way to do it)
[18:45] <emgent> NCommander: lol :)
[18:45] <emgent> s/NCommander/norsetto/
[18:45] <emgent> i'm back in 10 min.
[18:45] <NCommander> emgent: I thought about it, and the easiest way would simply create the wmaker-desktop meta-package with the necessary branding :-P
[18:46] <DktrKranz> k0p, yes
[18:48] <k0p> DktrKranz, we release stable. and i'm uploading the umit with corrections. after I do that can you take a look?
[18:48] <DktrKranz> k0p, sure :)
[18:50] <k0p> DktrKranz, uploading :)
[18:51] <DktrKranz> k0p, once REVU shows it, link new url
[18:51] <k0p> DktrKranz, sure ;)
[18:55]  * NCommander seriously needs to get his laptop fixed
[18:55] <NCommander> Maybe I can use wubi in the mean time on my old XP machine
[18:55] <NCommander> I'm just concerned about performance
[18:55] <DktrKranz> NCommander, is being stuck in win32 a critical issue?
[18:55] <DktrKranz> ;)
[19:08] <k0p> DktrKranz, I don't know why but REVU doesn't show yet recenly upload.
[19:10] <NCommander> DktrKranz: it's a Critical bug ;-)
[19:10]  * NCommander realizes he's also locked out of REVU's server
[19:10] <NCommander> *****
[19:12] <DktrKranz> NCommander, any delays in REVU upload management? (see above)
[19:12] <k0p> delays? hmm
[19:18] <k0p> I have a message at last of upload:  "Not running dinstall" What it means?
[19:19] <DktrKranz> don't worry about it, it's common
[19:20] <k0p> hmm ok
[19:21] <k0p> almost 30 minutes, weird..
[19:24] <NCommander> DktrKranz: dinstall is only run on scp/sftp uploads, right?
[19:25] <DktrKranz> AFAIK, no
[19:32] <k0p> DktrKranz, revu doesn't show nothing yet. can be a delay or upload again?
[19:33] <DktrKranz> dunno... a REVU admin might know better than me
[19:35] <k0p> I know one but he is away msg sleeping..
[19:36] <DktrKranz> sleeping is useless
[19:37] <sebner> sleeping is overrated :P
[19:38] <DktrKranz> sebner, easy to tell when you just had holidays :)
[19:39] <sebner> DktrKranz: well, not "real" holidays. culturedays :P
[19:39] <Lutin> geser: have you reported the limits.h issue to babel's upstream (asking to avoid reporting it twice)
[19:42] <fabrice_sp> k0p: I had this issue yesterday, and I had to 'migrate' my previous account revu to Launchpad OpenID, before uploading again
[19:44] <k0p> fabrice_sp, hmm
[19:44] <k0p> lauchpad?
[19:47] <fabrice_sp> On the top of REVU webpage, I have "Log in with Launchpad OpenID ", when previously I had a REVU id. After login in, I had to click on "Merge REVU accounts" to migrate old REVU account to OpenID, and been able to upload
[19:50] <k0p> oh yeah
[19:50] <k0p> let me try
[19:53] <k0p> fabrice_sp, I think you have reason.
[19:53] <k0p> I don't know about it.
[19:53] <k0p> some changes on revu. very nice now
[19:54] <fabrice_sp> yep: just discovered that yesterday ﻿:-D
[19:55] <k0p> thanks !
[19:57] <fabrice_sp> you're welcome ;-)
[19:57] <k0p> DktrKranz, http://revu.ubuntuwire.com/details.py?package=umit
[19:57] <geser> Lutin: no, feel free to report it upstream
[19:57] <k0p> DktrKranz, can you review, please? :)
[19:58] <Lutin> geser: ok. do you mind if I merge it ?
[20:00] <DktrKranz> k0p, downloading
[20:00] <k0p> :)
[20:01] <medo> how can I package a tcl/tk software?
[20:01] <medo> sorry for the naive question
[20:01] <medo> it is the first package i'm doing
[20:04] <TomJaeger> Could someone review http://revu.ubuntuwire.com/details.py?package=easystroke ? Thank you.
[20:05] <kdub> i want to maybe patch packages, or package things for intrepid, is there a site where packages like that are listed?
[20:07] <fabrice_sp> Just look for [needs-packaging] in LP
[20:10] <kdub> fabrice_sp: what is the 'merges' link in the topic about?
[20:11] <slytherin> geser: can you please confirm and ack bug 251973
[20:12] <stefanlsd> if im looking at a merge - how do i determine what to keep from the ubuntu stuff.   or, how do I determine if the ubuntu change is still relevant...
[20:13] <fabrice_sp> kdub: 'merges' indicate that the package exists in debian, and a merge is requested (that is update ubuntu version with debian version)
[20:14] <kdub> oh... i have a lot of questions about where i should help out. really, i think ill just send an email over the ubuntu-motu mailing list
[20:16] <slytherin> stefanlsd: read debian changelog ans see if any of the ubuntu changes have been merged in Debian version. This is first step. For others you may need to have deeper knowledge.
[20:16] <slytherin> !contribute | kdub
[20:16] <fabrice_sp> kdub: you can begin there: https://wiki.ubuntu.com/MOTU/GettingStarted
[20:18] <k0p> DktrKranz, are you seeing?
[20:18] <TomJaeger> I still don't understand the process, how exactly do I get someone to review my package?
[20:19] <DktrKranz> k0p, yes, almost done
[20:19] <k0p> ok :)
[20:19] <k0p> say something when finish :)
[20:20] <stefanlsd> slytherin: would they say they merge a change from ubuntu... or do we always need to check?
[20:20] <stefanlsd> slytherin: im guessing i'd take the two diff files.gz files between the two version and compare them?
[20:21] <slytherin> stefanlsd: you have to check. Changelog may not be always explicit. Also sometimes the some problem is fixed in Debian in adifferent way than Ubuntu. you have to evaluate which is better/suitable.
[20:21] <medo> I'm trying to package a software written in tcl/tk but there is no make file or install. what should I do?
[20:22] <medo> I tried looking into the packaging guide but couldn't find any thing usefull for me
[20:23] <slytherin> TomJaeger: by uploading it on revu
[20:23] <norsetto> Kopfgeldjaeger: you shouldn't take out newlines of course, just be carefull when you insert one that there is no blank space left
[20:23] <Kopfgeldjaeger> ah you
[20:23] <Kopfgeldjaeger> mean
[20:23] <Kopfgeldjaeger> foo bar \n
[20:23] <Kopfgeldjaeger> bar
[20:23] <Kopfgeldjaeger> ?
[20:24] <Kopfgeldjaeger> the space at the end of the line?
[20:24] <TomJaeger> slytherin, I've done that.  Also filed a bug report (LP: #254893)
[20:24] <kdub> fabrice_sp and slytherin, i appreciate the links, but i'm really just looking more to find out what people interested in becoming motu's do: package new things, or help out with repackaging and merging existing packages
[20:25] <slytherin> TomJaeger: Did you check if anyone has added any comment on revu for your package?
[20:25] <TomJaeger> slytherin, no comments there
[20:25] <slytherin> kdub: everyone has their own preference.
[20:27] <kdub> right, ive tried packaging from scratch, and would like to try repackaging things to fix bugs/get upgrades, but dont know what needs repackaging to see what its like
[20:29] <medo> I want to try packaging from scratch. I found one on LP bug#238612. but I can't get debuild to build the package?
[20:35] <medo_> I am trying to package coccinella 0.96 from scratch, it debends on a number of other packages when I run debuild it says unmet dependicies
[20:35] <medo_> how can I solve this problem
[20:35] <medo_> ??
[20:35] <medo_> thanks in advance
[20:36] <DktrKranz> k0p, commented
[20:36] <k0p> DktrKranz, ok
[20:36] <k0p> DktrKranz, let me check
[20:37] <DktrKranz> k0p, they should be easily fixed, other than them, packaging looks good
[20:37] <k0p> DktrKranz, first it is.
[20:37] <k0p> but twice..
[20:37] <k0p> sourceforge is crazy :S
[20:38] <DktrKranz> heh
[20:38] <k0p> second I don't have ideia how to fix it .. hmm
[20:40] <k0p> DktrKranz, how I should refer PSF licence?
[20:40] <Adri2000> DktrKranz: you're motu-sru aren't you? :)
[20:41] <DktrKranz> Adri2000, yep
[20:41] <DktrKranz> k0p, you should paste it in debian/copyright
[20:41] <k0p> DktrKranz, File utils/msgfmt.py is under PSF LICENCE v2. Only this on copyright?
[20:41] <k0p> hmm
[20:42] <k0p> paste and add this lines right?
[20:42] <slytherin> ahmed: post the error somewhere.
[20:43] <Adri2000> DktrKranz: I think I need you for bug #243722
[20:43] <DktrKranz> k0p, I'd put full license, or a link where it can be found
[20:44] <k0p> ok ;)
[20:44] <DktrKranz> Adri2000, ACKed, thanks.
[20:45] <ahmed> slytherin: this is the output i get from debuild
[20:45] <ahmed> dpkg-checkbuilddeps: Unmet build dependencies: libtls (>= 1.4)
[20:45] <ahmed> debuild: fatal error at line 993:
[20:45] <ahmed> You do not appear to have all build dependencies properly met, aborting.
[20:45] <ahmed> (Use -d flag to override.)
[20:45] <ahmed> If you have the pbuilder package installed you can run
[20:45] <ahmed> /usr/lib/pbuilder/pbuilder-satisfydepends as root to install the
[20:45] <ahmed> required packages, or you can do it manually using dpkg or apt using
[20:45] <ahmed> the error messages just above this message.
[20:45] <slytherin> ahmed: please don't flood the channel. use pastebin
[20:45] <ahmed> sorry what is that? I am really new to all of this
[20:46] <Adri2000> DktrKranz: thank you. now /me goes to find an archive admin :p
[20:46] <slytherin> !paste | ahmed
[20:46] <slytherin> ahmed: you said you are packaging from scratch. Exactly what steps have you followed till now?
[20:47] <DktrKranz> Adri2000, FYI, pitti manages SRUs every day. Probably it will be accepted before tomorrow's noon
[20:47] <ahmed> i ran dh_make
[20:48] <ahmed> to get the debian directory
[20:48] <Adri2000> DktrKranz: ok, asked anyway in -devel, otherwise will wait until tomorrow
[20:48] <ahmed> then I checked the control file to add the deps.
[20:50] <ahmed> then I thought I should and check wether i would be able to build or no but ended up with the error
[20:50] <slytherin> ahmed: you need to install the packages which need to build your app. Check 'Build-Depends' in control file and install all those packages.
[20:50] <DktrKranz> k0p, http://sf.net/umit/umit-(0|1)\.([0-9])\.([0-9])\.tar\.gz
[20:50] <DktrKranz> ugly, but it seems functional
[20:51] <ahmed> ok I thought the debuild actually do that. i guess i was mistaken
[20:51] <ahmed> thanks a lot for your help
[20:51] <k0p> DktrKranz, is functional?
[20:51] <k0p> but you comment this...
[20:51]  * norsetto hugs RainCT
[20:51] <slytherin> k0p: why so long url? Use the example form wiki.
[20:52] <k0p> slytherin, some trouble that I don't understand in sourceforge.
[20:52] <k0p> really.
[20:52] <k0p> I try push umit-6.04
[20:53] <k0p> I delete all on sourceforge .. nothing about it.
[20:53] <Flannel> DktrKranz: http://sf.net/umit/umit-[01](\.\d){2}\.tar\.gz
[20:53] <k0p> but it push this version.. I don't understand..
[20:53] <Kopfgeldjaeger> norsetto: cdbs automatically includes README and AUTHORS - should I manually remove them?
[20:54] <norsetto> Kopfgeldjaeger: there should be an option to tell cdbs what docs to install
[20:54] <DktrKranz> Flannel, nice try, but it's not correct, upstream has some tarballs which conflicts with good one
[20:54] <Flannel> DktrKranz: That's equivalent to yours, at least.
[20:55] <DktrKranz> it says "Newest version on remote site is .5, local version is 0.9.5"
[20:55] <k0p> yeah
[20:56] <slytherin> Kopfgeldjaeger: check id you have file named debian/docs.
[20:56] <Kopfgeldjaeger> slytherin: i had one, but already removed it
[20:57] <slytherin> Kopfgeldjaeger: keep the file and modify it to include/exclude the files you want
[20:57] <k0p> DktrKranz, it's a little weird .. where he found 0..5'
[20:57] <k0p> is it about regular expression?
[20:58] <Kopfgeldjaeger> slytherin: exclude? can i exclude a file in the docs-file or should I just not include the files I don't want there?
[20:58] <DktrKranz> k0p, btw, the slightly modified version I gave you seems OK, it's really ugly, but it does the job
[20:58] <slytherin> Kopfgeldjaeger: not include fiels you don't want
[20:58] <k0p> really? let me try
[20:59] <DktrKranz> if somebody has a better one, please fire it :)
[21:00] <tbielawa> RainCT, you got a minute to comment on a revu upload?
[21:00] <Kopfgeldjaeger> slytherin: cdbs still includes the files. -- dh_installdocs -pgtkhash ./README ./NEWS ./TODO ./AUTHORS
[21:00] <k0p> DktrKranz, I'll try find better. give a second :D
[21:00] <norsetto> Kopfgeldjaeger: if you look at /usr/share/cdbs/1/rules/debhelper.mk there is DEB_INSTALL_DOCS_<package> which should do what you need
[21:00] <Kopfgeldjaeger> super, thanks
[21:01] <DktrKranz> k0p, sure... just upload if you discover some, and I'll have a look
[21:01] <k0p> ok
[21:02] <k0p> DktrKranz, forget.. when i put \. inside ()
[21:02] <k0p> it dies.
[21:02] <k0p> :/
[21:02] <NCommander> ugh
[21:02] <slytherin> Kopfgeldjaeger: Someone will have to take a look at the package. and I am tired. :-(
[21:02] <NCommander> I've hit a new low
[21:02] <NCommander> I'm programming in COBOL
[21:02] <RainCT> tbielawa: Hey, I just arrived home. For a fast comment yes :)
[21:03] <Kopfgeldjaeger> slytherin: norsetto already solved the problem :o]
[21:03] <k0p> DktrKranz, uploading.
[21:03] <k0p> but this it's very strange..
[21:04] <k0p> * doesn't work :/
[21:04]  * NCommander plays with his COBOL compiler
[21:07] <k0p> DktrKranz, check it: http://revu.ubuntuwire.com/details.py?package=umit
[21:07] <tbielawa> RainCT, http://revu.ubuntuwire.com/details.py?upid=3182
[21:08] <tbielawa> that comment offer is open to anyone who can give me comments &/ advocates ;)
[21:09] <DktrKranz> k0p, advocated.
[21:10] <Kopfgeldjaeger> norsetto: Well, I have set DEB_INSTALL_DOCS_{myapp,ALL} to foo [for testing purposes], but the files are still included: dh_installdocs -pmyapp ./README ./NEWS ./TODO ./AUTHORS foo
[21:10] <fabrice_sp> tbielawa: just be sure that the lintian file is clean. You can also run lintian on the generated deb package, to check everything
[21:10] <k0p> DktrKranz, weeeeee :D thanks
[21:11] <norsetto> Kopfgeldjaeger: thats cdbs for you ;-) Dunno, try using -X, or check out what kind of distorted logic is being employed in that makefile I gave you
[21:11] <k0p> DktrKranz, I need 2 or 3 advocates? :)
[21:11] <DktrKranz> k0p, just 2
[21:11] <DktrKranz> one more, then :)
[21:11] <k0p> :)
[21:11] <Laney> Someone in motu-sru: Are upstream bugfix-only release candidates for SRU?
[21:11] <tbielawa> oh my. that's a new lintian error to me! Didn't even notice
[21:11] <k0p> ok
[21:12] <k0p> DktrKranz, very thanks for your attencion. :)
[21:12] <DktrKranz> Laney, it depends, if new upstream is just a bugfix and you can isolate test cases to see if bugs are really fixed, they can go in
[21:12] <norsetto> Kopfgeldjaeger: I avoid cdbs like pest for this very reason, it tends to do things its own way, and to bend it to my way it takes me far longer than to actually just use debhelper alone.
[21:13] <DktrKranz> k0p, np ;)
[21:13] <Laney> DktrKranz: Ah right, that's good then.
[21:13] <k0p> DktrKranz, so right now, what I need to do is find another person to review right?
[21:13] <DktrKranz> Laney, if upstream is *huge*, there are more issues... but if code change is low, it can be approved easily
[21:13] <DktrKranz> k0p, exactly
[21:14] <k0p> :)
[21:14]  * norsetto also notes that debhelper 7 seems way better than cdbs in this respect
[21:14] <k0p> RainCT, hi :P
[21:16]  * Laney needs to look into dh 7 at some point
[21:16] <fabrice_sp> How can I get Bug 242572 (https://bugs.launchpad.net/ubuntu/+source/wxsvg/+bug/242572) approved? I pasted the orig.tar.gz and the diff.gz file.
[21:17] <Laney> fabrice_sp: Someone will get round to sponsoring it in time
[21:17] <fabrice_sp> So, I only have to be patient? :-)
[21:18] <Laney> Yep. We're all in the same boat here!
[21:18] <Kopfgeldjaeger> norsetto: looks like my value is just appended to the standard-cdbs-var, even if I use =. -- http://rafb.net/p/pdbtBn47.html <- if i comment out this line in debhelper.mk, it works like expected. Maybe I should just leave README and AUTHORS where they are, as cdbs really wants to have them... although there's not much information in them
[21:19] <norsetto> Kopfgeldjaeger: I disagree, we should not let cdbs rule our policy
[21:19] <slayton> I'm trying to debug an error i'm getting when Installing a python module that I've packed into a deb here is a paste bin of the error: http://pastebin.com/m4756c1b0
[21:19] <Kopfgeldjaeger> OK.
[21:19] <slayton> I can't figure out what the error means as the error message isn't very descriptive
[21:19] <slytherin> fabrice_sp: when asking for upgrade you don't have to attach .orig.tar.gz. Only diff.gz. Of course it is expected that if for any reason if one can not use upstream tarball as it then you should provide get-orig-source target in debian/rules file.
[21:21] <fabrice_sp> slytherin:ok. In this case, it is the upstream tarball, so I shouldn't have attached it. thanks ;-)
[21:22] <cyberix> Could someone take a look at my package http://revu.ubuntuwire.com/details.py?package=pyliblo
[21:22] <cyberix> It seems to work
[21:23] <norsetto> Kopfgeldjaeger: do you use DEB_INSTALL_DOCS before or after the include?
[21:23] <Kopfgeldjaeger> damn
[21:23] <cyberix> This is the first time I create a source package that creates two different binary packages
[21:23]  * Kopfgeldjaeger <- idiot
[21:23] <cyberix> so there might be some error related to that
[21:24] <cyberix> also I'm not sure I fully understand the way stuff should be divided between different sections in rules
[21:24] <cyberix> There might be some error in dependencies also
[21:25] <Kopfgeldjaeger> norsetto: that solved the problem... of courser
[21:25] <Kopfgeldjaeger> -r
[21:25] <cyberix> it works in my installation
[21:25] <norsetto> Kopfgeldjaeger: :-)
[21:25] <cyberix> but not sure, if the build dependencies are correct
[21:25] <cyberix> also I'm not sure I understand the automatic generation of python and shlib dependencies
[21:26] <k0p> norsetto, can you take a look on my package? :)
[21:27] <norsetto> k0p: you don't really want me to do that ;-)
[21:27] <cyberix> There are atleast two projects using the pyliblo (that I'm aware of). I'd like to get it into Intrepid and then some application that uses it into intrepid+1
[21:27] <cyberix> but that depends on the upstreams
[21:28] <k0p> norsetto, well. why do you say that? lol
[21:28] <cyberix> so getting the library in early would allow the upstreams to try using their software with the packaged version
[21:28] <norsetto> k0p: url?
[21:29] <k0p> http://revu.ubuntuwire.com/details.py?package=umit
[21:29]  * k0p afraid .. 
[21:29] <k0p> :)
[21:31] <norsetto> k0p: I profoundly dislike having two desktop files, one for root and another not ...
[21:32] <joaopinto> can someone review and advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
[21:32] <norsetto> k0p: beside, you use su-to-root but I don't see a depends on menu?
[21:33] <k0p> norsetto, hmm
[21:34] <k0p> norsetto, we're working next release solve the roots issues.
[21:34] <k0p> norsetto, about the su-ro-root on menu. How to do that?
[21:34] <norsetto> k0p: I say, lets wait for it then ;-)
[21:34] <norsetto> k0p: you have to add it as a Depends
[21:35] <joaopinto> norsetto, I would appreciate your review again since most changes were based on your initial review :P
[21:35] <k0p> sure.
[21:35] <k0p> norsetto, but without change the adminstrator mode we can't enter in ubuntu? :s
[21:35] <norsetto> joaopinto: thats correct, thats way its good if somebody else looks at it with fresh eyes
[21:36] <norsetto> s/way/why ....
[21:36] <norsetto> k0p: extra blank line at the end of debian/control
[21:36] <joaopinto> well, at the current review rate I guess a lot of those packages will get hold on UVF :P
[21:37] <k0p> norsetto, fixed.
[21:37] <joaopinto> norsetto, btw, where did you get those lintian warnings from ? I have ran lintian from intrepid and didn't got those..
[21:38] <norsetto> joaopinto: from lintian :-) Did you run it on the binary packages?
[21:38] <joaopinto> ah, no, just on the source
[21:38] <norsetto> k0p: lots of blank spaces where you inserted \n in control
[21:39] <norsetto> k0p: why python twice as a depends?
[21:39] <k0p> it's about sqlite
[21:40] <norsetto> k0p: can you elaborate?
[21:41] <k0p> norsetto, yeap. python<=2.4 works with different sqlite
[21:41] <k0p> and it's another package
[21:41] <norsetto> k0p: so this package only works with 2.5?
[21:41] <k0p> after it, python integrate sqlite and have changes on packages
[21:41] <k0p> no
[21:42] <k0p> works with both
[21:42] <k0p> but if it is a condicional
[21:42] <k0p> python2.4 have differents dependences of python>=2.5
[21:43] <norsetto> k0p: suppose I have python2.4 (and python), will installing python-pysqlite2 make the package work for me?
[21:44] <k0p> y
[21:44] <norsetto> k0p: viceversa, if I have python2.5 and python, I don't need it, correct?
[21:45] <k0p> it's not viceversa. but yes. you don't need.
[21:47] <k0p> norsetto, about menu, depends is it a field?
[21:48] <norsetto> k0p: the Depends: in debian/control
[21:48] <k0p> oh
[21:48] <k0p> you talking about it.
[21:48] <k0p> yes!.. of course
[21:50] <k0p> norsetto, depends of gksu right?
[21:51] <norsetto> k0p: menu
[21:51] <k0p> norsetto, what about menu?
[21:52] <norsetto> k0p: the menu package
[21:53] <k0p> ok
[21:53] <sebner> gn8 folks
[21:53] <k0p> norsetto, done.
[21:53] <k0p> anymore norsetto?
[21:54] <norsetto> k0p: Files inside higwidgets/ are under LGPLv2 should be Files inside higwidgets/ are under LGPLv2.1
[21:54] <norsetto> k0p: you should use the copyright symbol instead of (C)
[21:55] <k0p> norsetto, symbol of copyright...
[21:56] <norsetto> k0p: Martin v. Loewis <loewis@informatik.hu-berlin.de> should be quoted as an author
[21:56] <k0p> norsetto, where?
[21:57] <k0p> oh it's wrong.
[21:57] <norsetto> k0p: in debian/copyright, he is an author in utils/msgfmt.py
[21:58] <k0p> ok
[21:58] <norsetto> k0p: you should also add a copyright for the package
[21:58] <k0p> in upstream authors?
[21:58] <k0p> norsetto, where?
[21:58] <norsetto> k0p: do you actually need debian/dirs?
[21:59] <norsetto> k0p: in debian/copyright
[21:59] <k0p> i'm in the top
[21:59] <k0p> norsetto, where I add author of Martin v. Loewis? in upstream authors?
[21:59] <norsetto> k0p: yes
[21:59] <k0p> and me too?
[22:03] <k0p> norsetto, added
[22:04] <k0p> norsetto, and copyright symbols replaced.
[22:04] <norsetto> k0p: what about dirs? do you really need it?
[22:05] <k0p> may be not let me check
[22:07] <RainCT> hi k0p
[22:07] <k0p> norsetto, don't need. removed.
[22:08] <k0p> RainCT, norsetto is review my package now. :) I'm run agains deadline.
[22:08] <Laney> Hmm, while we're in a reviewing mood - I have http://revu.ubuntuwire.com/details.py?package=goocanvasmm on REVU. Last plug for a few days, I promise :)
[22:08] <k0p> 28 august is limit date right?
[22:08] <norsetto> k0p: ok, don't forget the package copyright
[22:08] <k0p> norsetto, about symbol?
[22:08] <k0p> ops
[22:08] <norsetto> k0p: no, your copyright for the packaging
[22:09] <k0p> ok
[22:10] <norsetto> k0p: how should I know if I have to use umit as root or not?
[22:10] <RainCT> tbielawa:
[22:10] <tbielawa> RainCT, yes?
[22:10] <k0p> norsetto, hmm well umit show
[22:10] <k0p> if you try a scan that need permission
[22:10] <k0p> it's like wireshark..
[22:11] <norsetto> k0p: right, wouldn't be better to write something down in the description and README.Debian too?
[22:11] <RainCT> tbielawa: bah I didn't want to type enter :P. Anyway, I'm looking at your package now; I was away before (shower and dinner)
[22:11] <k0p> norsetto, about permissions?
[22:11] <k0p> I think it's not needed.
[22:12] <k0p> because user will know if it need root access.
[22:12] <norsetto> k0p: I do, I just installed it and I have no clue why I have two entries in my menu and which one I should use
[22:12] <norsetto> k0p: btw, I just used umit and it didn't start, typing umit in terminal gives me nothing
[22:14] <k0p> norsetto, what?
[22:14] <k0p> but runs by menu?
[22:14] <norsetto> k0p: ditto starting as root or with sudo umit in terminal
[22:14] <norsetto> k0p: nope
[22:15] <k0p> norsetto, why not? installed /usr/bin?
[22:15] <norsetto> k0p: yes, but does nothing
[22:16] <k0p> $ umit
[22:16] <k0p> $
[22:16] <k0p> something like that?
[22:16] <norsetto> k0p: yes
[22:16] <k0p> unbeliveble..
[22:16] <k0p> let me check
[22:19] <k0p> norsetto, no idea.
[22:19] <norsetto> k0p: me neither :-)
[22:19] <k0p> what do you have on
[22:19] <k0p> /usr/bin/umit
[22:21] <norsetto> k0p: what do you want to know?
[22:21] <k0p> norsetto, run python /usr/bin/umit
[22:22] <norsetto> k0p: this is the md5 088d2bad7411ee0e087c44707f4be873
[22:22] <k0p> it's the same
[22:22] <k0p> run the python /usr/bin/umit
[22:22] <k0p> to see whats happen
[22:23] <norsetto> k0p: I can run it in all flavours and sauces, still does nothing
[22:24] <norsetto> k0p: which isn't that bad, at least its not crashing ...
[22:24] <k0p> you're seeing ironic.
[22:24] <k0p> it doesn't run.
[22:28] <k0p> norsetto, so.. does not run..well..
[22:30] <k0p> norsetto, all dependencies are satisted?
[22:31] <norsetto> k0p: all the given ones
[22:31] <RainCT> tbielawa: http://revu.ubuntuwire.com/details.py?upid=3182 - most comments are just minor stuff, but there is some copyright information missing and the package FTBFS for me (with dpkg-buildpackage and all build dependencies satisfied)
[22:31] <k0p> norsetto, i'll test in a intrepid of a friend.
[22:32] <norsetto> k0p: ok, I have tested it both in intrepid and hardy
[22:33] <k0p> norsetto, and doesn't work in both?
[22:34] <norsetto> k0p: thats interesting, it does in intrepid now
[22:34] <k0p> in hardy works fine too.
[22:36] <norsetto> k0p: not for me
[22:37] <k0p> not only me test the package..
[22:38] <Kopfgeldjaeger> norsetto: got my message?
[22:39] <norsetto> Kopfgeldjaeger: email?
[22:39] <Kopfgeldjaeger> no, in this channel (router crashed...)
 norsetto: I uploaded a new gtkhash version to revu.
[22:40] <norsetto> Kopfgeldjaeger: ok
[22:40] <emgent> community council meeting.
[22:41] <k0p> norsetto, I add all
[22:41] <k0p> features on copyright that you request
[22:41] <tbielawa> RainCT, thanks for the notes.
[22:42] <k0p> norsetto, what do you do to it run on intrepid?
[22:43] <norsetto> k0p: just called the binary
[22:44] <k0p> but you say that he doesn't run.
[22:44] <k0p> and after you say that run.
[22:46] <k0p> norsetto, btw it's not to hardy. it's to intrepid.
[22:47] <norsetto> k0p: I know, yet I would like to understand why, remember that we could backport it
[22:47] <k0p> backport? to hardy?
[22:48] <k0p> norsetto, I would like to reproduce your bug.
[22:48] <k0p> But really.. I don't have idea
[22:49] <norsetto> k0p: its a standard up-to-date hardy install, package compiled with an hardy pbuilder
[22:50] <norsetto> k0p: not that it matters, I also tried the intrepid package since there is nothing specific and behaves the same
[22:50] <k0p> the same what? doesn't run?
[22:51] <k0p> norsetto, hmm
[22:52] <k0p> norsetto, can you see if /usr/bin/umit line 38 it's False?
[22:52] <norsetto> k0p: I can help with debugging, but I know nothing about python, if you think there are breakpoints I can add just tell me (but not now, I'm just too tired)
[22:54] <k0p> norsetto, no worries. just say about line 38 :)
[22:54] <k0p> and python version too :)
[22:54] <norsetto> k0p: I removed the whole thing, what was it, the one about DEVELOPMENT something?
[22:55] <k0p> y
[22:55] <norsetto> k0p: yes, it was false
[22:55] <k0p> ok
[22:55] <k0p> and you python version?
[22:56] <norsetto> k0p: both 2.4 and 2.5 and python points to 2.5
[22:56] <k0p> ok
[22:56] <k0p> should be works
[22:59] <k0p> norsetto, after run umit just echo $?
[22:59] <k0p> please
[23:02] <norsetto> k0p: 1
[23:06]  * norsetto goes to bed
[23:06] <k0p> cya norsetto and thnks
[23:08] <k0p> RainCT, can you test my package? i'm trying to see one issue
[23:36] <k0p> DktrKranz, are you there?
[23:39] <k0p> DktrKranz, I lost advocate. I upload new package with minor fixes like remove spaces etc.
[23:39] <k0p> DktrKranz, is it normal?