[00:00] <nxvl> RainCT: http://augeas.net/tour.html
[00:02] <RainCT> uhm.. curious syntax :)
[00:02] <nxvl> yep
[00:03] <nxvl> you can also use "ls" to browse the tree
[00:03] <RainCT> actually.. it's quite cool
[00:04] <nxvl> s/quite/really/g
[00:04] <RainCT> :)
[00:06] <nxvl> i love ir
[00:06] <nxvl> it*
[00:06] <TheMuso> RainCT: Nice to know someone is willing to try and find i18n bugs.
[00:06]  * nxvl lows his head
[00:06] <RainCT> nxvl: You've a comment, http://revu.ubuntuwire.com/details.py?upid=2723
[00:07] <RainCT> TheMuso: :)
[00:07]  * nxvl gives RainCT a hard HUG!!!
[00:07] <nxvl> RainCT: thank you!
[00:07] <RainCT> nxvl: no, thank *you* ;)
[00:08]  * RainCT hugs nxvl back
[00:11]  * nxvl blogs
[00:11] <RainCT> raphink: I guess your advocation for augeas (http://revu.ubuntuwire.com/details.py?upid=2723) is still valid?
[00:21] <nxvl> RainCT: what the procedure now? you will upload it? i need to ping someone else? i need to something else?
[00:21] <nxvl> RainCT: where can i keep track of the aproval by the archive admins
[00:22] <RainCT> raphink: either raphink needs to confirm that his advocation is still valid and then one of us can upload it, or you can search someone else to advocate it
[00:22] <RainCT> *eh, nxvl
[00:23] <RainCT> nxvl: and about the NEW queue, it's somewhere in Launchpad but I don't know the URL
[00:24] <nxvl> i will send raphink an e-mail and compy it to you
[00:28] <Grackle> So... Realtek released a GPL'd driver for their RTL8187SE device (a miniPCI wireless device). It required some modification to compile, but it now works in Ubuntu Hardy. I'd like to get it into the repositories now. Is that possible?
[00:28] <nxvl> RainCT: send it
[00:28] <Grackle> I've never submitted a package before.
[00:30] <RAOF> Grackle: It's unlikely to make it into (base) Hardy, given that Hardy's been released.  However, you could get it into Intrepid and then request a backport.
[00:32] <RAOF> Grackle: You're probably looking for https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages to start with.
[00:32] <Grackle> Okay, thanks.
[00:33] <TheMuso> I'd also suggest getting the driver into the intrepid kernel directly.
[00:36] <Grackle> Yeah.. I don't know how to do that. I have a driver. It compiles and works. I've never done any ubuntu development before, so getting into that process is difficult. I've read through a lot of stuff on the wiki and I watched the Daniel Holbach's ubuntudevel videos on youtube, but I haven't really gotten started.
[00:36] <Grackle> s/is difficult/is the difficult part
[00:36] <RAOF> Grackle: Joining #ubuntu-kernel may be worthwhile; the kernel is a bit special :)
[00:37] <slayton> how do you setup a deb so then when installed it adds itself to the Application Menu
[00:37] <Grackle> Alright, I'll do that.
[00:37] <RAOF> A good default option is to file a bug against $PACKAGE (in this case, the linux-source package) with a pointer to the patch/driver.
[00:40] <Grackle> ok
[00:43] <RainCT> slayton: installing a .desktop file
[00:43] <slayton> .desktop file?
[00:44] <RainCT> slayton: https://wiki.ubuntu.com/MOTU/Packages/DesktopFiles  http://standards.freedesktop.org/desktop-entry-spec/latest/   http://standards.freedesktop.org/menu-spec/latest/apa.html
[00:44] <slayton> thanks
[00:44] <RainCT> yw
[00:55] <Grackle> What do I do if the package is not in launchpad?
[00:55] <RainCT> Grackle: what package is it?
[00:56] <Grackle> Ohhh, lovely. I think I just broke something.
[00:56] <Grackle> linux-source-2.6.24
[00:56] <Grackle> Hmm, weird.
[00:57] <Grackle> I got a 404 error when I tried to install that package, then I couldn't apt-get update due to a lockfile that had not been removed
[00:57]  * Grackle deleted it and everything is at least pretending to work
[00:58] <directhex> https://launchpad.net/ubuntu/+source/linux-meta
[01:00] <RainCT> Grackle: you've to look for the source package in Launchpad, which in this case is "linux". One way to get it is checking on http://packages.ubuntu.com
[01:01] <Grackle> https://launchpad.net/ubuntu/+search?text=linux-source-2.6.24 I was trying to search for it there
[01:01] <Grackle> I'll try your link
[01:01] <RainCT> directhex: is it linux or linux-meta?
[01:02] <directhex> hm, you're right
[01:03] <Grackle> Oh, by the way, I tried to publish my gpg key to the ubuntu keyserver so I could add it to my launchpad account, but it can't find it. :/
[01:03] <Grackle> Looks like linux-386 is the one I want.
[01:17] <RainCT> good night
[01:18] <slangasek> ScottK: I don't see mercurial in hardy-backports/new now; I guess someone else got to it?
[02:11] <ScottK> slangasek: Looks like.  Thanks for checking.
[05:31] <Festor> raphink, ajmitch, siretart, when re-sync the REVU uploaders keyring?
[05:34] <ion_> Could someone please nuke both http://revu.tauware.de/details.py?package=compcache and http://revu.tauware.de/details.py?package=compcache-debian? Thanks.
[05:35] <persia> Festor: It mostly gets done on request.  I'll resync now.
[05:35] <persia> ion_: why?
[05:36] <ion_> I wrote that in their comments.
[05:36] <Festor> persia, I have a strange problem. I upload packages to REVU but the system does not identify my account
[05:37] <persia> Festor: What do you mean?
[05:37] <Festor> wait a moment
[05:37] <ion_> I’ll reupload a new compcache after some changes, and it will be much different than what i uploaded as compcache earlier. Not based on any upstream tarball. It might be confusing if there are debdiffs that mostly just remove an entire upstream project.
[05:38] <Festor> I think I found the solution
[05:38] <persia> ion_: I suppose that makes sense.
[05:38] <ion_> And after a discussion, it became apparent that compcache-debian should just be called compcache, so i’ll upload a new version of what i uploaded as compcache-debian. as compcache.
[05:41] <Festor> I can change my Revu password?
[05:42] <ion_> persia: Thanks!
[05:42] <persia> ion_: Please don't upload stuff whilst I'm trying to nuke it :)
[05:42] <persia> Festor: Not easily.  Why do you wish to?
[05:42] <ion_> persia: I did the upload after i noticed both compcache and compcache-debian had disappeared. Sorry if i did that too early.
[05:43] <persia> ion_: For something to be nuked, it must first be archived.  If something is uploaded after archiving, it restores it.
[05:43] <Festor> Unless the process is not easy no matter
[05:43] <ion_> Ok, sorry. Additionally, i thought uploads would be processed the next time in 6 minutes anyway.
[05:44] <persia> ion_: Perhaps.  Anyway, everything all gone now (I think).
[05:44] <ion_> Thanks. Ok to upload now?
[05:44] <persia> Indeed.
[05:45] <ion_> Apparently the files are already on the server. I guess it will just get processed in five minutes.
[05:45] <persia> Festor: The keyring sync just completed, but I'm guessing you are encountering something else.  Could you restate your problem?
[05:46] <ion_> persia: Btw, i bet spammers love all the email addresses on REVU main page, and even more on http://revu.tauware.de/uploaders.list :-)
[05:46] <Festor> now I have no problem
[05:47] <persia> ion_: Possibly.  Note that every email address in either of those lists is already mirrored on heaps of public keyservers, so it's not like a first exposure or anything.
[05:47] <ion_> Good point
[05:47] <Festor>
[05:47] <Festor> One question, when the package to upload revue, I have to wait for the review?
[05:48] <Festor> I uploaded http://revu.ubuntuwire.com/details.py?package=amsn-transparent
[05:48] <Festor> and http://revu.ubuntuwire.com/details.py?package=amsn-desktop-integration
[05:48] <Festor> all plugins for amsn
[05:48] <persia> Festor: The guideline is that you may advertise your package here once per day.  Note that time-zones differ, so it's safest to wait at least 25 hours before each advertisement.
[05:49] <Festor> ook
[05:52] <Festor> and if I see a package that need work I can fix that package?
[05:53] <ion_> Alright, http://revu.tauware.de/details.py?package=compcache should now be in accordance with the compcache spec.
[05:54] <dholbach> good morning
[05:58] <ajmitch> hello dholbach
[05:58] <Festor> persia, if I see a package that need work I can fix that package?
[05:59] <dholbach> hi ajmitch
[06:00] <persia> Festor: A package in the repositories, or one on REVU?
[06:00] <Festor> on REVU
[06:00] <tuxmaniac> dholbach: hi
[06:00] <persia> Festor: It's considered polite to contact the uploader and collaborate on the package.
[06:01] <Festor> ahh, ok, thanks! :D
[06:01] <dholbach> hi tuxmaniac
[06:01] <tuxmaniac> dholbach: may I pm?
[06:01] <dholbach> sure
[06:04] <RAOF> ion_: The very briefest of reviews starts with "do you _really_ want the version to be '0ubuntu1'"?
[06:04] <ion_> raof: I’m going to try to get that to debian as “1”.
[06:06] <RAOF> _Really_ cdbs? :)
[06:07] <persia> RAOF: Are preaching dh7 again?
[06:07] <RAOF> No.
[06:07] <persia> s/e p/e you p/
[06:07] <ion_> Doesn’t get much prettier than http://revu.tauware.de/revu1-incoming/compcache-0807070650/compcache-0ubuntu1/debian/rules IMO :-)
[06:07] <RAOF> But dh5 would quite possibly be clearer.
[06:08] <persia> ion_: Why install -D?  If you're going to use CDBS, you may as well try to get everything in dh_install
[06:09] <ion_> persia: To my knowledge, it doesn’t handle either changing files’ modes or renaming them. compcache-script needs to be chmoded 755 (dh_fixperms doesn’t handle that because of the directory) and initramfs-hook needs to be saved as .../hooks/compcache.
[06:09] <RAOF> The package long description could be a little more descriptive :)
[06:10] <ion_> raof: Thanks, i’ll look into that.
[06:12] <RAOF> I _think_ compcache-script violates policy (I don't believe that /bin/sh is expected to support "local foo=bar").
[06:13] <ion_> Ok. I assumed “if dash thinks it’s ok, it’s ok”, but i guess not.
[06:14] <RAOF> I've fallen into that trap, too :)
[06:14] <ion_> Works in whatever sh OpenBSD has, too.
[06:15] <RAOF> http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
[06:16] <ion_> Thanks, had just opened that.
[06:16] <RAOF> So, everything supports your use of local, but it's not quite required by policy :).
[06:17] <ion_> Wait. Doesn’t it say scripts may assume sh supports local?
[06:18] <RAOF> Yes.  But "may or may not support arguments more complex than simple variables".  So 'local foo; foo = bar' is OK, but 'local foo=bar' is not.
[06:19] <ion_> Ah. I’ll change that then.
[06:19] <RAOF> This is the sort of hair-splitting that's not terribly necessary; I don't believe that what you've done will break anything, even though a strict reading of policy allows /bin/sh to not support it.
[06:21] <RAOF> For those not also idling in #debian-devel: http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 .  Heh.
[06:21]  * RAOF is startled.
[06:21] <ajmitch> RAOF: rather amusing, isn't it?
[06:22] <RAOF> ajmitch: Seen comment 17?
[06:22]  * ajmitch tries to imagine any canonical developer responding in that fashion
[06:22] <ajmitch> yep
[06:23] <RAOF> It does boggle the mind, yes.
[06:24] <RAOF> ion_: Is debconf-updatepo _really_ meant to be called in the clean target?
[06:24] <RAOF> It's entirely possible that it is, but it seems quite strange to do that.
[06:26] <ion_> raof: po-debconf(7): The debconf-updatepo program is idempotent, it modifies PO files only if their content has been updated.  Thus the best solution to provide up-to-date PO files in your source package is to call this command from the "clean" target of the debian/rules file.
[06:28] <RAOF> ion_: Thanks.  I'm (obviously) not familiar with po-debconf, or really debconf at all.
[06:29] <ion_> I uploaded a version with the ‘local’ thing fixed, but i didn’t fix the long description yet. The upload should be handled in a minute, i think.
[06:30] <ion_> Comment #17 :-D
[06:30] <RAOF> Yes. :)
[06:31] <ion_> http://revu.tauware.de/diff.py?upid1=2726&upid2=2727
[06:32] <RAOF> ion_: Is there any benchmarks of this you've seen in your travels?  How much of a win, and in what situations is it a win?
[06:33] <siretart> ion_: openbsd has ksh
[06:33] <ion_> raof: Sorry, i didn’t understand. Do you mean the debconf-updatepo thing, or?
[06:33] <RAOF> ion_: Of compcache.
[06:34] <RAOF> ion_: debconf-updatepo is fairly obviously not performance-critical :)
[06:34] <ion_> raof: http://code.google.com/p/compcache/wiki/LTSPPerfSummary http://code.google.com/p/compcache/wiki/LTSPPerf
[06:35] <ion_> Also, the Ubuntu spec: https://blueprints.launchpad.net/ubuntu/+spec/compcache
[06:42] <RAOF> Hm.  Cool.
[07:29] <Hobbsee> persia: twitch
[07:29] <Hobbsee> persia: blink.  and dholbach just went and ack'd it, too.
[07:31] <persia> Hobbsee: The bugs were valid, despite the source, no?
[07:32] <Hobbsee> persia: i doubt it.
[07:32] <Hobbsee> persia: there's two debian revisions for the first one, and only one change mentioend.
[07:33] <Hobbsee> there's a person who has commented on the bug, saying it's wrong
[07:34] <persia> Hrm.  Grumble.
[07:34] <Hobbsee> persia: and he's incorrect in the second bug anyway.
[07:34] <Hobbsee> persia: there rae two changes, and the second is a maintainer change.
[07:35] <Hobbsee> he's correct that it can be synced, but is completely incorrect in the other points.
[07:36] <persia> Hobbsee: After review, I still say these are valid bugs: on the other hand, I don't believe they in any way contribute to "A solid indication of changes in the work style".
[07:36] <Hobbsee> it looks like the first one is correct, if, in fact, the debian change does fix the ubuntu issue.
[07:37] <Hobbsee> persia: i'm more pointing out that if anyone else wrote those sort of justifications for bugs, which are demonstrably incorrect, even though teh final conclusion is right, they'd get spoken to, and wouldn't get an immediate ack.
[07:38] <dholbach> Hobbsee: I did not give it an immediate ACK
[07:38] <persia> Hobbsee: I agree with that.  As I said, the *bugs* are valid.  I think it would benefit from updated descriptions with the ACK.
[07:39] <Hobbsee> persia: so, either, a) kmos is getting it easy, or b) daniel isn't watching to see if changes are correct - or if he is, isn't ensuring that all the parts of the person's statements are correct, which is still probably important.
[07:39] <dholbach> granted, the first thing I did was triage the sponsoring queue instead of first checking whose bug it is
[07:39] <persia> Hobbsee: Also, the discussion with most people would be of the nature of "Well, this isn't quite correct: please fix it".  In this case, it's really "Don't do that".
[07:40] <Hobbsee> persia: oh, sure.  but in the normal case it would be "Well, this isn't quite correct: please fix it" as you say, rather than "yes, this is correct"
[07:40] <persia> dholbach: Hobbsee's point stands that the descriptions are in fact completely incorrect: they oughtn't be ACK'd without an update.
[07:40] <Hobbsee> dholbach: and a one word "ACK" with no other comment was what I was classifying as an immediate ack.
[07:40] <dholbach> I'll update them after I walked the dog
[07:40] <dholbach> but I'm not making it easy for anybody
[07:42] <Hobbsee> persia: in the case of those bugs, there is *no* indication at all that any parts of the bugs are incorrect.  presumably, this is not a good thing, as other contributors are looking at sync requests from others, checking that they themselves are doing the right thing.
[07:43] <persia> Hobbsee: I see your point.  I expect this will be addressed after the abovementioned dog walking is complete.
[07:43] <Hobbsee> persia: which is a dangerous culture change, imo.
[07:44] <Hobbsee> (for anyone to be filing bugs like that, not just the aforementioned one)
[07:44]  * RAOF wonders what this discussion is about.
[07:44] <dholbach> Hobbsee: what do you mean by culture change?
[07:44] <persia> Hobbsee: Which is the dangerous change?  Not correcting the bug when ACK'ing, or waiting for it to be corrected?
[07:44] <dholbach> I updated bug 245706
[07:45] <Hobbsee> persia: having bugs with incorrect comments, but with correct end results that get an ack, and are very likely to not be gone back and changed.  If the people can get away with it once, then they're more likely to do it repeatedly.
[07:46] <Hobbsee> ubuntu development is still very quick that expecting people to go and update their bugs, post ack, is unlikely to happen
[07:46] <persia> Hobbsee: In the general case, I agree with you.  In this specific case, I believe Daniel is currently updating the bugs, and willing to wait a few minutes.
[07:47] <dholbach> Hobbsee: I'm sorry if I didn't check closely enough and overlooked things, but I'll repeat again: I'm not making it easier for anybody
[07:47] <dholbach> it's not a culture change, but rather lack of coffee
[07:48] <Hobbsee> persia: true.  i'm only discussing the general case here, because the particulars of this case should be solved by other means (the previous MC decisions should be enforced here)
[07:57]  * dholbach now goes walking the dog
[08:12] <nxvl> dholbach: hi
[08:12] <nxvl> dholbach: did you got my mail?
[08:22] <dholbach> nxvl: the one about Pisco? :)
[08:23] <nxvl> heh
[08:23] <nxvl> yes, also
[08:23] <nxvl> but no
[08:23] <nxvl> the other one
[08:23] <nxvl> the one about the video
[08:23] <\sh> uh I just read kmos again
[08:24] <dholbach> nxvl: ah yeah - got that one, but didn't get to reply to it yet :)
[08:24] <nxvl> isn't he like banned or something?
[08:24] <nxvl> dholbach: i have already the getting started one
[08:24] <\sh> nxvl: na i read it in "third person mode"
[08:24] <Hobbsee> nxvl: yeah, but he's still filing sync requests anyway.
[08:24] <nxvl> dholbach: i just need to mix it
[08:24] <nxvl> \sh: heh, ok
[08:24] <nxvl> Hobbsee: does he?
[08:25] <Hobbsee> nxvl: https://lists.ubuntu.com/archives/motu-council/2008-July/001266.html
[08:25] <dholbach> nxvl: woah - great
[08:25] <dholbach> nxvl: good work! :-))))
[08:25] <nxvl> Hobbsee: with a little of self love i would go far far away from ubuntu development on his shoes
[08:27] <Hobbsee> nxvl: what do you mean?
[08:27] <bliZZardz> guys, can someone enlighten me on what happened and why marco was banned?
[08:27] <nxvl> Hobbsee: that if i were kmos, and after everything every one told him i wouldn't be involved (or near) in the development of ubuntu
[08:27] <bliZZardz> kmos = marco?
[08:28] <persia> bliZZardz: Briefly, he filed lots of sync requests that were not well researched, and did not respond well to requests to stop.  Over time, this escalated to the current situation.
[08:28] <Hobbsee> nxvl: ah, yes
[08:28] <Hobbsee> bliZZardz: https://lists.ubuntu.com/archives/motu-council/2007-December/000574.html and beyond (motu list also has some info)
[08:28] <bliZZardz> persia : "did not respond well to requests to stop" --> that is dangerous!!!
[08:30] <nxvl> bliZZardz: also norsetto and dholbach spend a lot of time with him trying to make things better, but he didn't respond
[08:31] <nxvl> dholbach: what did you use to edit the videos and make only one?
[08:31] <Hobbsee> personally, i most liked the removal requests for packages that weren't in the archive.  i thought that really took the cake.
[08:31] <nxvl> dholbach: because i have the video of me talkin and the screencast and i need to make one video mixed, but i don't find an apropiate tool
[08:31] <dholbach> nxvl: it was Tony Whitmore and Alan Pope who did that - I don't know what they used
[08:32] <dholbach> nxvl: does the Screecast wiki talk about this?
[08:32] <nxvl> dholbach: nope
[08:32] <bliZZardz> what really really amuses me is that i find #ubuntu-XXX channels to be the most helpful and the people are so damn great - i didnt ever imagine that such situations would arise. It has been like utopia for me here
[08:32] <nxvl> dholbach: just about mixing video with audio
[08:32] <nxvl> dholbach: i will ping popey
[08:32] <nxvl> popey: ping
[08:32] <nxvl> :D
[08:33] <Hobbsee> bliZZardz: those cases are relatively rare.
[08:33] <nxvl> dholbach: because it will need a spanish speaker to mix them
[08:33] <RAOF> I personally can't remember one other than Kmos, but I've got a rubbish memory.
[08:33] <bliZZardz> Hobbsee : yea , can see it. am sure this place rocks :)
[08:34] <Hobbsee> RAOF: i don't think there has been - although, there's been some other disturbing stuff over the weekend.
[08:34] <bliZZardz> Hobbsee : disturbing stuf??? like??
[08:34] <Hobbsee> but not on the same level as him.
[08:34] <persia> I'd like to note that even in the case of Kmos, there were many months of helpful guidance before it became an issue.
[08:35] <gaspa> hi all.
[08:35] <Hobbsee> bliZZardz: a core developer who appears to be unaware of where to find information on, and how to file, basic MOTU/core dev tasks such as sync requests.
[08:35] <nxvl> yes
[08:35] <nxvl> what persia says is really true
[08:35] <bliZZardz> the #ubuntu-bugs becomes exceptionally silent on weekends - and it scare me sometimes when i am triaging full throttle and there is no one to answer my Qs -- hope i dont face the same fate as marco ;)
[08:35] <Hobbsee> bliZZardz: you actually listen to what you're told.
[08:36] <geser> dholbach: I've read the discussion about bug 245706. The Debian maintainer has also commented on it that a sync is ok. How to proceed now? Do you want to wait on a comment from Kmos?
[08:36] <nxvl> there was people (as i said before) working with him on 1 on 1 basis for making things work
[08:36] <persia> bliZZardz: As long as you're engaged, it's exceedingly unlikely.
[08:36] <nxvl> but he didn't respond
[08:36] <dholbach> geser: I just asked for some Ubuntu testing
[08:36] <Hobbsee> bliZZardz: if you're paranoid, have a look at the sponsor feedback (see december archives for that list), and see if you do the same :)
[08:36] <dholbach> geser: and I thanked Carsten
[08:36] <nxvl> raphink: around?
[08:37]  * bliZZardz gets back to work.. wishes others a fine monday :)
[08:37] <dholbach> bliZZardz: and the same to you! :)
[08:37] <bliZZardz> Hobbsee : lol ..dont scare me now :P
[08:37] <Hobbsee> bliZZardz: no, it's supposed to make you not scared :P
[08:38] <ion_> raof: I changed the description: http://gitweb.heh.fi/?p=ion/ubuntu/compcache.git;f=debian/control;hb=HEAD
[08:38] <RAOF> heh is a great dns component.
[08:38] <bliZZardz> Hobbsee : quick comment - dont find any dec archives (https://lists.ubuntu.com/archives/ubuntu-dct/)
[08:39] <raphink> hi nxvl
[08:39] <persia> bliZZardz: That'd be the Debian Collaboration Team archives.
[08:39] <RAOF> ion_: Much better.
[08:40] <nxvl> raphink: i have got the 2nd ACK on augeas, but we were un sure if yours is still valid
[08:40] <raphink> nxvl: can we talk in 2 hours?
[08:40] <bliZZardz> persia : then? isnt that teh same link?
[08:40] <raphink> I'm busy ;)
[08:40] <RAOF> ion_: I think that's pretty much ready to go, then.
[08:40] <nxvl> raphink: well i'm going to sleep in a minute, but i send you an email
[08:40] <raphink> ok
[08:40] <raphink> sure
[08:40] <raphink> good night
[08:40] <ion_> raof: Cool
[08:41] <nxvl> raphink: the only thing i need is, that your ack is still valid please sponsor the package
[08:41] <raphink> ok
[08:41] <nxvl> s/your/if your/g
[08:41] <ion_> REVU noticed the upload (with the new description) a minute ago.
[08:41] <nxvl> raphink: or just make rainct know that is still valid
[08:41] <nxvl> raphink: or if not, make me know about it to found one more ack
[08:41] <nxvl> :D
[08:43] <persia> bliZZardz: Yes, but you likely want to look at the motu-council archives
[08:43] <slytherin> Hi, I have a question about motu contributors team. What is the advantage of being member of this team over someone who is simply working on his own to fix packaging issues and adding them to sponsors queue.
[08:43] <bliZZardz> persia : ok thanks..will look at it later. have to rush back to work now...
[08:44] <RAOF> slytherin: You get a shiny new icon on your LP page.
[08:44] <RAOF> slytherin: Oh, and an @ubuntu.com address.  But that's about it.
[08:44] <nxvl> dholbach: aren't you in turkey?
[08:45] <persia> Well, you can also carry an Ubuntu business card, and get an Ubuntu IRC cloak.
[08:45] <dholbach> nxvl: nah, in Berlin :)
[08:45] <ion_> Also free beer for life from Canonical.
[08:45] <ion_> Just kidding. ;-)
[08:45] <nxvl> dholbach: you didn't go to GUADEC?
[08:45] <dholbach> nxvl: nope
[08:45] <\sh> persia: I wonder what is an ubuntu business card?
[08:45] <nxvl> dholbach: i thought you were going to be there
[08:46] <nxvl> \sh: just a bussiness card that says ubuntu
[08:46] <dholbach> nxvl: I'll leave for holidays in a week though :)
[08:46] <\sh> nxvl: you mean I'm allowed to print the ubuntu logo on the card?
[08:46] <RAOF> ion_: The trick is to _find_ that beer.  I had to do down to the subbasement.  It was in an decommissioned lavatory, with a sign saying "beware of the lepoard".
[08:46] <nxvl> \sh: yep
[08:46] <ion_> raof: :-D
[08:46] <nxvl> \sh: if you are an ubuntu member
[08:47] <slytherin> why does that team exist then? does it guarantee faster processing of requests in queue if you are a member?
[08:47] <ion_> raof: Did you have to look the wording up? :-)
[08:47] <persia> \sh: https://wiki.ubuntu.com/BusinessCards
[08:48] <nxvl> dholbach: to turkey? or just to the beach
[08:48] <RAOF> ion_: Hell, no.  Also, that's a paraphrase anyway.  I can't do the interragatory style on my own :)
[08:48] <ion_> Heh
[08:48] <dholbach> nxvl: http://daniel.holba.ch/blog/?p=125
[08:48] <RAOF> slytherin: When that team was created, people were concerned about exactly this problem :)
[08:48] <dholbach> nxvl: no beach this time :)
[08:49] <RAOF> slytherin: It doesn't really _do_ anything.  It's not a necessary step on the path to MOTU, you don't get extra LP privelages, and you don't get better sposorship.
[08:49] <slytherin> RAOF: Ok. You answered my second question without me asking it.
[08:50] <slytherin> RAOF: That is "it is necessary step on path to MOTU".
[08:50] <RAOF> slytherin: "Is it a necessary step on the way to MOTU-hood?" :)
[08:50] <RAOF> Heh.
[08:50] <nxvl> dholbach: oh yes! i saw it some weeks ago
[08:50] <nxvl> dholbach: funny picture btw
[08:50] <persia> slytherin: That team exists as the mechanism by which MOTU Council may grant Ubuntu Membership.  The Community Council made the determination that this ought be a separate team.
[08:50] <geser> Laney: re your ffmpeg->ffmpeg-free rebuilds: do you plan to provided debdiffs for the rebuilds?
[08:50] <RAOF> Basically, it's meant to be a reward.  A badge to commemorate your many MOTU contributions.
[08:51] <dholbach> nxvl: it's the best that I could do with GIMP :)
[08:51] <slytherin> RAOF: persia: Thanks for information. I guess I will apply for the membership before month end.
[08:52] <nxvl> dholbach: yes, we are developers, not graphic designers
[08:52] <dholbach> hehehe :)
[08:53] <geser> Laney: what is exactly the reason for the rebuilds? because I fixed a FTBFS in moc recently and wonder why it needs a rebuild now.
[08:54] <Hobbsee> bliZZardz: because you're looking at the wrong team - you want https://lists.ubuntu.com/archives/motu-council/2007-December/
[08:55] <mouz> dholbach: On https://wiki.ubuntu.com/PackagingGuide/Howtos/DesktopFiles it says 'Verify that the package is not listed below as not needing a .desktop file'. But I can not find such a list. Would you know where I can find it?
[08:57] <dholbach> #
[08:57] <dholbach> #
[08:57] <dholbach> When looking for a program that needs a .desktop file, please consider using the following: [WWW] http://people.ubuntuwire.com/~persia/find-missing-desktop
[08:58] <dholbach> unfortunately that link is down it seems
[08:58] <persia> Yeah :(  Probably best to comment out for now.  I hear that it might work again later in this month, but haven't been told any definite date.
[08:58] <dholbach> mouz: sorry if the answer does not help you very much - I didn't write the article myself but integerated it into the Packaging Guide, so it might not be very helpfule :-/
[08:58] <persia> Alternately, we could put it back as an attachment to the wiki page...
[08:58] <nxvl> persia: btw, is imbrandon still alive?
[08:59] <persia> nxvl: Yes.
[08:59] <nxvl> persia: but he isn't involved on the community anymore, is he?
[09:00] <persia> mouz: There isn't really a list of packages determined not to need .desktop files any more.  There was one in the wiki, and you might be able to find it by digging history, but it wasn't being kept up to date.
[09:00] <persia> mouz: The short list is: Window Managers, programs that don't have sensible defaults, programs that only act on files, rather than having a standard interface, and programs with no GUI.
[09:01] <nxvl> mouz: best is to check if the package ships with one or not using less on the .deb file
[09:01] <nxvl> mouz: and take in account what persia just pointed
[09:01] <nxvl> btw, i don't know why mutt has a .desktop file
[09:02] <nxvl> or use to have
[09:02] <persia> mutt has a .desktop file?!?  That's rather surprising.
[09:02] <mouz> I'm packaging stjerm which is not yet on the archives. It starts up invisible. Therefore if a user clicks a menu item, nothing seems to happen. So I'm thinking to not include a .desktop file. Can I do so?
[09:03] <persia> mouz: Starting up invisible is exactly the sort of behaviour which indicates something oughn't have a .desktop file.
[09:04] <nxvl> persia: at least it use to have one
[09:04] <mouz> persia: good :) Also I would like to know whether I can use README.Debian to document the fact. I searched but could not find whether that is the way to do it.
[09:05] <nxvl> persia: i remember seeing it before
[09:07] <persia> mouz: Unless upstream ships a .desktop file, and you're explicitly not using it, I'd not bother with the documentation.  README.Debian should explain anything that is interestingly different from upstream in the installed binary package: source changes typically don't belong there, rather reserved for README.Debian-source
[09:08] <mouz> ah yes. persia, dholbach, nxvl: thanks a lot
[09:09] <Iulian> Good morning.
[09:09] <nxvl> now need to sleep
[09:09] <nxvl> i need to learn how to use mutt, but i will be tomorrow
[09:09] <nxvl> see you all
[09:09] <nxvl> have a nice day!
[09:10] <nxvl> raphink: please don't forget to take a look at augeas when you have time
[09:10] <nxvl> raphink: thank you very much for it!
[09:16] <popey> nxvl: pong#
[09:17] <nxvl> popey: i have already send you and e-mail (as well as daniel)
[09:22] <nxvl> popey: can you please review it
[09:35] <popey> ok
[10:05] <bliZZardz> dholbach_ , dholback : can you plz share the link which shows the bug stats?
[10:05] <RAOF> Gah.  Checking the mono library API sucks when the previous package never built in intrepid.
[10:08] <huats> TheMuso: are you around ?
[10:19] <stgraber> I had a quick look at the init.d script and didn't see anything that would make it do nothing (like looking for a conf file, .pid file, ...)
[10:19] <stgraber> oops
[10:34] <dholbach> bliZZardz: you mean http://daniel.holba.ch/5-a-day-stats/ ?
[10:47] <bliZZardz> dholbach : yea - same one. But it looks like some problem there. What does the count indicate?
[11:25] <hefe_bia> Hi! I am looking at bug 114565. An udev rule is needed that is not tied to a particular package - where should it go? It's own package?
[11:28] <persia> hefe_bia: It's probably better to tune the rules in module-init-tools than try to have a floating rule.
[11:31] <hefe_bia> ah, ok. Thanks!
[11:56] <sistpoty|work> hi folks
[11:58] <sebner> huhu sistpoty|work
[11:58] <sistpoty|work> hi sebner
[12:26] <bliZZardz> hello
[13:46] <bddebian> Heya gang
[13:47] <sistpoty|work> hi bddebian
[13:47] <bddebian> Hi sistpoty|work
[13:49] <geser> Hi bddebian
[13:49] <bddebian> Heya geser
[13:57] <nedko> is it good idea to have debian subdir in upstream?
[13:57] <broonie> nedko: No.
[13:57] <broonie> (apart from anything else, it causes hassle if you have to delete a file they've added
[13:58] <slytherin> nedko: It is ok to have it in upstream svn but the source tar distribution should not contain it.
[13:59] <nedko> thanks
[14:00] <nedko> i plan to create/update some linux audio (jack) related packages
[14:20] <jpds> RainCT: Yeah, it's right. But I had gone to bed when you sent the message :)
[14:22] <hefe_bia_> Hi! What to do if upstream includes binaries of another GPL licensed program in the tarball? (but without any license stating that they do so)
[14:22] <wgrant> hefe_bia_: You tell them to stop it.
[14:28] <lukehasnoname_> What does triage mean, in the "bug treatment" sense?
[14:30] <broonie> lukehasnoname_: Initial checking, prioritisation and classification. It's from the medical term http://en.wikipedia.org/wiki/Triage
[14:31] <lukehasnoname_> Right, I know what it means IRL. But I don't get how it's used in bug terms. If something is triaged with classification "critical", then it wouldn't be triaged anymore, would it? It would be "Confirmed"
[14:42] <dholbach> https://wiki.ubuntu.com/Bugs/Status
[14:42] <nedko> is artfwo comming here?
[14:51] <nxvl> raphink: around?
[14:51] <raphink> yes,
[14:51] <nxvl> raphink: about augeas, is your ack still valid?
[14:52] <raphink> it's still valid as far as I'm concerned
[14:54] <nxvl> RainCT: around?
[14:54] <nxvl> RainCT: great!
[14:54] <RainCT> nxvl: yes
[14:54] <nxvl> raphink: great
[14:55] <nxvl> RainCT: raphink sais his ack is still valid
[14:55] <nxvl> RainCT: can you please sponsor the package
[14:55] <RainCT> nxvl: Great :)
[14:56] <RainCT> raphink, can you upload it, please? I've to go in a while and would like to finish something else first
[14:56] <raphink> nxvl: in a near future, it might be interesting to provide additional plugins
[14:56] <raphink> nxvl: since augeas is made by a fedora dev, it could be nice to have plugins for Debian specific conffiles
[14:56] <raphink> I can upload it RainCT
[14:58] <RainCT> raphink: ok, thanks
[15:01] <nxvl> raphink: https://wiki.ubuntu.com/UbuntuCentralizedServiceAdministrator/Augeas
[15:03] <raphink> hmmm our network team closed some streams without telling us
[15:04] <raphink> I have to ask for the ftp to be open to the Internet again :s
[15:04] <raphink> shouldn't be long though
[15:10] <raphink> nxvl: done
[15:13] <ScottK-laptop> nxvl: Congratulations.
[15:14] <nxvl> raphink: thanks
[15:14] <nxvl> RainCT: thanks
[15:14] <nxvl> ScottK-laptop: thanks!
[15:14] <raphink> is it your first package nxvl?
[15:15] <nxvl> yep
[15:15] <nxvl> well almost
[15:15] <raphink> congrats :)
[15:15] <nxvl> because on terminator upstream helped me a lot with debianization
[15:15] <nxvl> so it doesn't count
[15:16] <raphink> hehe ok
[15:17]  * nxvl HUGS raphink and RainCT
[15:17] <ScottK-laptop> nxvl: Even with help, it still counts.
[15:17] <raphink> thank you for your work, nxvl
[15:18] <RainCT> nxvl: congratz :)
[15:18] <raphink> https://launchpad.net/ubuntu/intrepid/+queue?queue_state=0&queue_text=
[15:18] <ScottK-laptop> nxvl: Particularly since this is not a simple package.
[15:18] <nxvl> ScottK-laptop: i mean on terminator (the previous one) this one has been entirely by myself
[15:19] <nxvl> and yes
[15:19] <nxvl> augeas it not a simple package
[15:19] <nxvl> not at all
[15:19] <ScottK-laptop> Ah.  My mistake.
[15:19] <nxvl> \o/
[15:19] <ScottK-laptop> nxvl: Double congratulations then.
[15:19] <nxvl> heh
[15:19] <nxvl> thanks
[15:20] <ScottK-laptop> nxvl: You might consider asking for a backport to Hardy to support testing and experimentation once it's out of New.
[15:20] <raphink> yes, that would be nice
[15:20] <nxvl> ScottK-laptop: i didn't thought about it, but it will be nice
[15:20] <nxvl> ScottK-laptop: i will
[15:21] <nxvl> ScottK-laptop: btw, i don't remember if i include you on my mail, but can you please review https://wiki.ubuntu.com/UbuntuCentralizedServiceAdministrator/Augeas and check if everything on the mail side is in there?
[15:21] <ScottK-laptop> nxvl: You did include me.
[15:22] <nxvl> i knew i couldn't forget you
[15:22] <nxvl> i'm just to sleepy now
[15:22] <nxvl> i have just woke up
[15:22] <ScottK-laptop> nxvl: You ought to add amavisd-new, spamassassin, and clamav to your list.
[15:22] <nxvl> ScottK-laptop: can you do it please
[15:22] <ScottK-laptop> From a mail admin perspective those get configuration changes a lot more often than core things like Postfix.  Sure.
[15:23] <raphink> a dput one could be nice, too
[15:23] <raphink> :)
[15:23] <raphink> if you can add it at the same time ScottK-laptop
[15:23] <nxvl> raphink: yes, but that wouldn't be in a close future
[15:23] <raphink> it's very easy to do nxvl
[15:23] <raphink> that's why I'm mentionning it
[15:23] <nxvl> raphink: i have some goals to reach for intrepid and i need to focus myself on them
[15:24] <raphink> ok
[15:24] <raphink> where can we contribute the lenses ?
[15:24] <nxvl> raphink: launchpad?
[15:24] <raphink> bugs?
[15:24] <nxvl> i have a post with all that information
[15:24] <nxvl> but my blog is down
[15:24] <nxvl> raphink: yep
[15:24] <ScottK-laptop> raphink: Sorry, already down.
[15:24] <ScottK-laptop> down/done
[15:24] <raphink> ok, np
[15:25] <ScottK-laptop> nxvl: Do lenses get added to the augeas package or to the package they are for?
[15:26] <nxvl> raphink: augeas is the first step for: https://wiki.ubuntu.com/UbuntuCentralizedServiceAdministrator
[15:26] <nxvl> raphink: which i spec in the future will become ubuntu control center or something
[15:26]  * raphink thinks of augeas as a brick to integrate in puppet
[15:27] <nxvl> ScottK-laptop: i will add them to augeas it self
[15:27] <raphink> I don't really think of managing one single machine
[15:27] <nxvl> ScottK-laptop: i have made a binary package just for the lenses
[15:27] <raphink> but that's nice nxvl
[15:27] <raphink> for sure, using augeas would be great to improve the configuration API
[15:27] <raphink> s/API/tools/
[15:28] <nxvl> raphink: yes, the long term goal is to make manage more than one machine from a client over the network
[15:28] <raphink> nxvl: do you have experience with configuration management tools like cfengine or puppet?
[15:29] <nxvl> not that i remember (on the development front)
[15:29] <nxvl> but as a sysadmin i have used some of them
[15:29] <raphink> ok
[15:29] <raphink> I see
[15:30] <nxvl> also i developed one for specific requirements on samba
[15:30] <nxvl> i needed to use almost same configurations over a LOT of samba servers
[15:30] <nxvl> so i use some script that do it for me
[15:30] <nxvl> changing some data from server to server, depending on the requirements
[15:30] <nxvl> it was a nightmare
[15:31] <nxvl> i'm out of battery and need to go work
[15:31] <nxvl> see you all
[15:31] <nxvl> and thanks!
[15:31] <nxvl> bye!
[15:31] <nxvl> have a nice day
[16:05] <YokoZar> ScottK / ScottK-laptop: Thanks for the ack on the wine SRU.  I'm a bit confused about what happens next though, since there's already a Wine in hardy-backports.  Do we upload that same package to hardy-proposed, or one with an incremented version?
[16:05] <ScottK> YokoZar: We ask pitti if he'll copy it from backports or if he wants it to go through proposed.
[16:34] <DRebellion> Would somebody mind reviewing my package? http://revu.ubuntuwire.com/details.py?package=monkeystudio Thanks ; )
[16:49]  * sistpoty|work heads home... cya
[16:53] <geser> DRebellion: FTBFS for me on intrepid AMD64
[16:53] <DRebellion> geser, hmm, i have only tested on intrepid i386
[16:53] <DRebellion> which built fine
[16:54] <DRebellion> geser, would you mind attatching the log to the bug page? I have to go out for a bit.
[16:54] <null_vector> Who can I talk to about nvidia issues on intrepid?  I can file a bug now but all it will say is it doesn't work.  Nothing shows up in the X log.
[16:55] <geser> DRebellion: can do
[16:55] <DRebellion> geser, thanks
[16:57] <geser> done
[16:59] <geser> null_vector: have you read https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025723.html?
[17:01] <null_vector> no, I hadn't.  Thanks.
[17:38] <hunmaat> hi.
[17:39] <ScottK> Dear upstream: Please don't just write "Apply a selection of Debian upstream patches." in your changelog.  There are a bunch of them and it'd make my life easier if you'd say which ones they were ...
[17:39] <sebner> ScottK: rofl O_o
[17:41] <hunmaat> I've commented to a bug in hwtest, the ubuntu package. it's maintainers are the motu. there is a hwtest launchpad project. it has different bugs list. shouldn't these be linked somehow?
[17:41] <hunmaat> or at least some information about this project on the package's overview page
[17:43] <Festor> One question, I can import packages form GetDeb.net to revu? (I have the permission of GetDeb admin)
[17:45] <ScottK> Festor: Sure, but they need to meet Ubuntu quality requirements.
[17:45] <Festor> I working in that
[17:45] <Festor> :D
[17:45] <ScottK> By their own admission, getdeb has different standards.
[17:45]  * sebner asks himself why these folks don't contribute to ubuntu that way
[17:45] <ScottK> sebner: I've asked them to and they declined.  Feel free to try again.
[17:45] <Festor> O.o
[17:46] <joaopinto> I will not answer that one again :)
[17:46] <ScottK> Festor: In general, if there is a demand for a package from outside the official repositories, we ought to try and get it in if we can.
[17:46] <sebner> joaopinto: and for me? ^^
[17:47] <joaopinto> sebner, to summarize because I have had too many conversations a long time ago.. different goals
[17:48] <joaopinto> we had some merge efforts, I have started to work on a wiki page with dholbach, but then I got out of time and interest to get back to it
[17:48] <sebner> joaopinto: well I know that you are some kind of "bleeding edge" but what speaks again to contribute to ubuntu and upload them to revu?
[17:49] <Festor> Peace to all... :D
[17:50] <joaopinto> sebner, the issue is not with the revu upload, someone would have to follow-up those revu uploads, I tried myself with 1 package, 2 years ago, I found it a painful process, not getting the proper (or at least expected) attention
[17:50] <ScottK> joaopinto: Would you be willing to consider pointing your web site at .deb's from hardy-backports where they exist?
[17:50] <joaopinto> anyway it seems Festor will be starting picking it up
[17:51] <sebner> joaopinto: I see, yes attention is a problem. not interested to become a MOTU and help out there? ;)
[17:51] <SWAT> is there a good intro to packaging with scons? (or a great example package).
[17:51] <joaopinto> ScottK, there are a few limitations on using repositories for our distribution model, replacing with a repository is not an option yet...
[17:52] <ScottK> joaopinto: I'd ask you to consider that then for the future.
[17:52] <ScottK> I think it would be good to reduce duplication of effort.
[17:52] <joaopinto> sebner, with all respect I have for the MOTUs, sometimes I found it too much political and uninteresting, and sometimes a few bad experiences don't help either
[17:53] <joaopinto> ScottK, we will, we also have more requests than we can handle
[17:53] <sebner> joaopinto: I see but double work is not good and btw it seems that you are a good at packaging so a loss for us
[17:54] <joaopinto> and there is something about MOTUs which I really hate, mixing packaging with bug fixing :P
[17:55] <azeem> how do you disentangle them?
[17:56] <joaopinto> packaging is about integration, mostly integrating upstream into the distribution, a packager skills are mostly distro oriented
[17:56] <azeem> so you think all bugfixing should happen upstream?
[17:56] <joaopinto> bug fixing requires real application development skils, and it is much more efficient when executed by people familiar with the code from a global perspective
[17:57] <broonie> You need both, especially when it comes to the release freeze phase.
[17:57] <joaopinto> yes, mostly, except for any integration specific patches
[17:58] <broonie> When freezing people from the distro side need to be able to assess the risks and effects of changes, especailly from upstreams with unrelated schedules.
[18:01] <joaopinto> distros should still do the QA on those changes, but still the fixes should be handled upstream
[18:01] <azeem> joaopinto: sure, except that it's not always practicable to do so
[18:04] <joaopinto> sure, a balance is required between both, and right now I see too much being brought to the distro side
[18:05] <broonie> Especially note that lots of upstreams explicitly don't care about anything except their current release (clamav ftw!)
[18:08] <Laney> geser: Someone (forget who, sorry) said that it would be enough to just file the bugs
[18:08] <Laney> Also, I filed bugs against all the packages that came up on the NBS list and built successfully - thought those would all be the ones that needed it
[18:44] <Festor> One question, I can package a app with freeware license?
[18:44] <Festor> for Revu of course
[18:45] <Festor> I talk about mercury messenger
[18:45] <slytherin> Festor: what do you mean by freeware license?
[18:46] <Festor> ehh, freeware? I dont understand
[18:46] <Festor> slytherin, http://en.wikipedia.org/wiki/Mercury_Messenger
[18:47] <Festor> http://en.wikipedia.org/wiki/Freeware
[18:47] <Festor> I see that unrar is in Ubuntu repositories
[18:47] <Festor> and that package has freeware license
[18:47] <Festor> but...
[18:48] <Festor> I dont know if I do something in special for make a package with freeware license
[18:49] <Festor> I should indicate also in copyright file in other file?
[18:49] <slytherin> Festor: is the source available?
[18:50] <Festor> freeware =! source code available....
[18:50] <Festor> but...
[18:50] <Festor> http://thebachman.info/images/stories/Mercury/Versions/mercury-messenger-1.9.tgz
[18:50] <Festor> Mercury messenger is written in Java
[18:52] <slytherin> Festor: It could go in restricted, but you will have to talk with some other developers here. I am not sure how many will be interested in sponsoring a messenger with no source even though it is free to distribute.
[18:53] <Festor> slytherin, http://thebachman.info/images/stories/Mercury/Versions/mercury-messenger-1.9.tgz
[18:53] <Festor> and this?
[18:53] <Festor> I dont know if this is "source code" I am not a expert in Java apps
[18:54] <slytherin> Festor: I am sorry I can not verify right now if it is a souce. My bandwidth is all used up in some other work.
[18:54] <Festor> ok, no problem
[18:56] <AstralJava> I don't see any .java files inside the tarball.
[19:04] <null_vector> Any reason why debuild would delete a manpage inside debian/ when building?  Starting to get annoying.
[19:10] <azeem> null_vector: if you think debuild is to blame, try dpkg-buildpackage instead
[19:14] <null_vector> no the debian/rules was specifically deleting the manpage for some reason
[19:19] <Festor> When I upload a package for REVU, I should put Mantainer field as: "Ubuntu MOTU Developers<EMAIL_ADDRESS>[19:19] <Festor> or I can use my name&e-mail?
[19:22] <mouz> Festor: Maintainer should be as you say. XSBC-Original-Maintainer should hold the packager's name+email (which could be yours). See also https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[19:22] <Festor> ok, thanks
[19:23] <simu> hi, after i install freebsd, what desktop environment do I have
[19:24] <simu> can I chose between kde or gnome at the isntallation procedure'
[19:25] <azeem> simu: Ubuntu does not support freebsd, AFAIK
[19:26] <simu> shit wrong channel
[19:26] <simu> m sorry
[19:43] <AstralJava> Okay, I've got a problem. I worked out a working debian/ inside an unwrapped tarball, and managed to create a good *.dsc with debuild -S -sa, with which I could produce nice binary .debs with pbuilder. Once this process was executed, I initiated the same structure as a bzr branch, and uploaded to lp.net. Of course, now the same procedure won't work, debuild -S -sa doesn't run successfully.
[19:43] <AstralJava> What is the correct procedure to maintain such a structure?
[19:44] <azeem> I know nothing about bzr, but for those people who do, it will be crucial to quote the error you get with debuild now
[19:48] <null_vector> did you "bzr add debian/" ?
[19:48] <AstralJava> azeem: Silly me, of course. :) http://pastebin.ubuntu.com/25755/
[19:51] <AstralJava> null_vector: I forget that precisely, but if you browse the code inside lp.net, debian/ is there.
[19:52] <Adri2000> AstralJava: what about bzr-builddeb?
[19:54] <james_w> AstralJava: you want to add "-i" to the debuild command
[19:55] <james_w> it excludes .bzr etc. from the package, and so you don't get those problems, as well as not including stuff in the source package that doesn't really want to be there.
[19:55] <AstralJava> Adri2000: Might work, just gotta add a debian/watch file
[19:56] <AstralJava> james_w: Thank you! That was the answer. :)
[20:09] <kumy> can someone do a review to my packages?
[20:09] <kumy> http://revu.ubuntuwire.com/details.py?package=webilder
[20:09] <kumy> http://revu.ubuntuwire.com/details.py?package=hwreport
[20:09] <kumy> thanks :)
[20:13] <Falken> Hi MOTU
[20:31] <slayton> if I want to add my application to the Applications Menu do I specify where in the menu it goes in the control file or in the desktop file?
[20:32] <AstralJava> .desktop file
[20:32] <slayton> AstralJava, thanks... and if I want to create a new folder in the application menu how do I do that?
[20:32] <pochu> what for?
[20:32] <AstralJava> slayton: Not sure about that. Normally we should refer to freedesktop.org's recommendations.
[20:33] <slayton> ok
[20:33] <AstralJava> But if you have good reason, I suppose it works. Second pochu's question, though. :)
[20:34] <slayton> what for?  I am hoping to package an entire suite of applications that we would like to have their own folder under applications
[20:34] <pochu> what kind of apps are they?
[20:35] <pochu> OpenOffice doesn't have its own menu section, for example
[20:35] <Falken> quick question on my first package : there is no manpage with the binary, is it mandatory ? if so, should I ask the upstream author to produce one or write it myself ?
[20:35] <pochu> Falken: write it yourself
[20:35] <slayton> they are applications that are specifically designed to visualize and collect electrophysiological data from some hardware that we have built
[20:35] <pochu> Falken: and send it to upstream :)
[20:35] <pochu> there's a Science section I believe
[20:36] <slayton> you're right about OpenOffice but ubuntu does have an "Office" entry
[20:36] <Falken> okay ! thanks mentor ;)
[20:36] <Falken> so I assume it's mandatory.
[20:37] <slayton> pochu, so when I installed crossover it created a menu entry for "Windows Apps"
[20:38] <pochu> Falken: it may be uploaded without it, but it's better to create them
[20:38] <Falken> sure, of course.
[20:39] <pochu> slayton: these are the official categories: http://standards.freedesktop.org/menu-spec/latest/apa.html
[20:40] <pochu> slayton: if any of those fits your needs, I think it would be better to use them instead of creating another section. OTOH I'll probably never use those apps...
[20:40] <slayton> pochu: thanks! a second question, when I add my repository to a computer the applications show up under synaptic but not under Add/Remove programs...  what is required to get apps to show up under Add/Remove
[20:50] <pochu> slayton: I think it (gnome-app-install) uses the app-install-data package, so it looks for files in /usr/share/app-install/desktop/, I'd say
[20:51] <pochu> slayton: but no package in the Ubuntu archive should do that manually, so don't do that if you want to have your packages in the official repositories
[20:55] <slayton> pochu, none of these apps will end up in the official repos
[20:57] <slayton> so if I want my apps to show up there, I need to put the desktop file in app-install/desktop and if i want them to show up in the menu I need to put a desktop file in /usr/share/applications, right? just trying to make sure I'm getting this
[20:57] <slayton> also after I add a desktop file how do I reload the application menu to get the new app to show up?
[21:03] <james_w> slayton: if you have a .desktop file in the package that is installed in to /usr/share/applications/ then it will get a menu entry. It will then get included in a later version of app-install-data automatically.
[21:03] <james_w> you should look at dh_desktop which should take care of the other bits, but won't install the .desktop file for you.
[21:04] <slayton> ok thanks... so i'm just messing around now and creating some desktop files by hand... how can i get those entries to show up automatically? do i have to reload X?
[21:13] <james_w> slayton: no, update-desktop-database I believe
[21:16] <Falken> question : how do I integrate the manpage in the package ?
[21:17] <Falken> I made a mybinary.1 , but don't know where to put it, and if I need to add rules to deploy it
[21:17] <joaopinto> I believe that you only need update-desktop-database if your .desktop provides a mime association, otherwise dropping the file on /usr/share/applications is sufficient
[21:19] <james_w> Falken: check out dh_installman
[21:19] <Falken> woohoo ok thanks :P
[21:21] <mouz> Would somebody mind reviewing my package (a light weight terminal emulator)? bug 216603 , http://revu.ubuntuwire.com/details.py?package=stjerm . Thanks :)
[21:23] <Iulian> Falken: Well, I use pod2man. Create a file named binary.pod with your man page. After that create a manpages file and write debian/binary.1
[21:25] <Iulian> Falken: In debian/rules, build target, you should have something like pod2man --section=1 --release="" --center "" debian/binary.pod > debian/binary.1
[21:25] <Iulian> Falken: And remove binary.1 in the clean target.
[21:26] <Iulian> That should do it.
[21:26] <Falken> woah
[21:26] <Falken> okay then
[21:26] <Iulian> Falken: Don't forget to call dh_installman
[21:27] <Falken> yep it's done, obviously it wasn't enough :)
[21:29] <Falken> lulian: I just need to touch a file named binary.pod with nothing in it ?
[21:31] <Iulian> Falken: That file should contain your manual page.
[21:32] <Falken> oh ok
[21:33] <Falken> my page is already formatted, so I guess I can skip that part
[21:33] <Falken> hum, no I can't, it's built during the package install
[21:35]  * Iulian is going to sleep.
[21:35] <Iulian> Good night.
[21:35] <Falken> good night lulian, thanks for helping
[21:36] <null_vector> Falken: easiest way isd to create a debian/manpages file with a list of the manapages you want installed
[21:38] <Falken> null_vector : and ... that's it ?
[21:38] <Falken> it is easy indeed :)
[21:40] <ScottK> Adri2000 or Lutin: DaD seems broken.  No component pages.
[21:41] <ScottK> leonel: I don't see any security issues in today's clamav releases.  Do you concur?
[21:43] <Falken> it works ! thanks null_vector :D
[21:54] <leonel> ScottK: All ok
[21:55] <ScottK> leonel: Thanks for checking.
[22:09] <silwol> hi!
[22:09] <silwol> how do I get a .orig.tar.gz when a debian/rules get-orig-source updates directly from svn?
[22:10] <bdrung> try to run "debian/rules get-orig-source"
[22:10] <silwol> yes, that updates my current directory to the recent svn version
[22:11] <silwol> but there is no .orig.tar.gz file or .orig directory after that...
[22:12] <silwol> ah, just found it... this package stores it in ../tarballs
[22:17] <Adri2000> ScottK: thanks, DaD migrated to a new server recently, and it seems everything broke
[22:36] <RainCT> Adri2000: btw, anything new regarding MoM?
[22:36] <Adri2000> nope........
[22:39] <RainCT> Adri2000: uhm.. I thought Mark asked for the features to be implemented in a reasonable amount of time? and now it's blocking on them... :P
[22:41] <wgrant> RainCT: Ah, I thought the ball was on your side of the court.
[22:41] <wgrant> So they might too.
[22:43] <Adri2000> wgrant: see branches at https://code.launchpad.net/merge-o-matic, they've been waiting for feedback for weeks
[22:43] <Adri2000> RainCT: yes he did :)
[22:44] <wgrant> Adri2000: Oh, hmm. I see.
[22:45] <slayton> on: http://standards.freedesktop.org/menu-spec/latest/apcs03.html  it states that .menu files need to be saved to: sysconfdir/menus/application-merged/ for menu items to show up as new folders... can anybody tell me where sysconfdir/menus/application-merged/ is in Hardy Heron?
[22:45] <null_vector> Do you need to mention debian/control in the changelog when using update-maintainer?
[22:46] <wgrant> slayton: /etc/xdg/menus/applications-merged
[22:47] <slayton> ty
[22:47] <RainCT> null_vector: Well, that depends on you. The entry that update-maintainer adds is enough, but if you mention that the change was in debian/control even better.
[22:48] <slayton> wgrant: so I add my .menu files there... and my .desktop and .directory files to /usr/share/applications/  ?
[22:48] <RainCT> null_vector: if you do other changes in debian/control then I'd say add a "* debian/control:" bullet and list the maintainer change and the other changes as sub-points of it
[22:48] <wgrant> slayton: Why are you adding a new folder? That is generally a bad idea.
[22:49] <null_vector> RainCT: One more debdiff: bug #246406.  I just created the bug.  Should I subscribe anyone?
[22:49]  * RainCT looks
[22:50] <slayton> people have been telling me all day that adding your own menu entries is discouraged.... I'm building a suite of scientific software... it will be installed on machines that will only be used for this softwware... we'd like to give them their own menu entry
[22:50] <slayton> but is my above question correct about locations?
[22:51] <RainCT> slayton: for the .desktop file, yes. (I don't know about the others)
[22:51] <slayton> ok thanks... like I said i've been extensively reading the documentation at freedesktop.org but it isn't making perfect sense
[22:51] <wgrant> slayton: How do you know it is going to be used only on machines with that restriction?
[22:53] <slayton> well I guess somebody could run other things on these machines... but most people who have access to these machines have their own laptops/desktops and they won't want to run anything else on the machines they use for experiments
[22:54] <slayton> i mean these machines are being bought exclusively for doing experiments
[22:54] <RainCT> null_vector: looks good, subscribe ubuntu-universe-sponsors
[22:54] <Falken> copyright question : the upstream under X11/MIT License, and my package is under GPL. how should I fill the License field in debian/copyright ? is it even possible to have upstream in a type of license and package in another ?
[22:54] <wgrant> slayton: But what about people outside your organisation..?
[22:54] <wgrant> Falken: It's generally a good idea to match your packaging to the software.
[22:55] <RainCT> null_vector: (note that it's good practice to explain what the patch is for in the "## DP:" line of the .dpatch file)
[22:55] <slayton> umm... they debs will be hosted on a public repo but unless they have the hardware to interface with the software there won't be any reason for them to use the software
[22:55] <slayton> and the hardware they buy from us
[22:55] <Falken> okay then, no problem. thanks wgrant !
[22:55] <null_vector> RainCT: sorry, forgot about that.
[22:56]  * null_vector goes home
[22:56] <RainCT> Falken: if by "license field" you mean the  "License:" header, that is about the upstream tarball
[22:56] <RainCT> null_vector: good night :)
[22:58] <slayton> anyway the /etc/xdg/menus/applications-merged was exactly the answer to my question!  Thank you guys are always very helpful
[22:58] <Falken> RainCT: absolutely. I got it from there, but I was wondering if I had to add the GPL for the package itself
[22:59] <RainCT> Falken: I guess the "The Debian packaging is licensed..." lines which come in dh_make's template are enough
[23:00] <RainCT> Falken: and I think I have some package where upstream is BSD and the packaging is GPL (without the header, just those two lines) and so far nobody has complained about it :)
[23:00] <Falken> okay
[23:00] <Falken> to be honest I don't care, but I want to do it the right way :)
[23:02] <Falken> you're right, dh_make's template wrote "package licensed under the GPL, see above"
[23:02] <Falken> I'm only removing "see above" then :P
[23:02] <RainCT> Falken: uh, "see above" or "see /usr/share/common-licenses.."?
[23:03] <Falken> it's "see above" , referring to the License:  text
[23:03] <Falken> but if the text isn't GPL, it doesn't make sense
[23:03] <RainCT> it should be something like:  The Debian packaging is (C) 2008, Your Name <email> and is licensed under the GPL, see `/usr/share/common-licenses/GPL'.
[23:03] <Falken> oh ok ! great
[23:04] <RainCT> or just license it under the same license as upstream uses..
[23:04] <tester_> I'm not sure if I am in the right place.  I was told someone here might be able to help me fix my aprutil1 package to contain apr_dbd_mysql.so
[23:04] <RainCT> well, I'm off.. good night
[23:04] <ion_> ` as a left single quotation mark is an abomination. :-)
[23:05] <Falken> good night RainCT, thanks for helping :D
[23:05] <RainCT> ion_: heh. tell the dh_make guys, that's copy-pasted ;)
[23:05] <RainCT> Falken: no problem :)
[23:10] <bdrung> wgrant: last time you helped me packaging matplotlib. so i have subscribed you to bug #246408
[23:11] <Falken> updated flabber package on REVU - Please review http://revu.ubuntuwire.com/details.py?package=flabber
[23:11] <Falken> thanks in advance
[23:12] <tester_> I am would like to update my aprutil1 source package to include apr_dbd_mysql.so.  I have downloaded the source.  How do I edit the configuration and rebuilder/install the package with the apr_dbd_mysql.so module?
[23:20] <dushara> Hi, I need help registering a project
[23:31] <emgent> heya