[00:11] <pochu> devfil: pong
[00:11] <devfil> pochu: I'm uploading wxwidgets2.8
[00:11] <devfil> I've already uploaded it, but I've changed a bug number in the changelog
[00:12] <pochu> uploaded to where?
[00:12] <devfil> so I'm reuploading it
[00:12] <devfil> http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8
[00:12] <devfil> REVU
[00:12] <pochu> let me know tomorrow, I'm off to bed now
[00:13] <devfil> pochu: I'm uploading it now, so the best think is to wait ;)
[00:13] <devfil> and it needs attention
[00:14] <pochu> devfil: you could save bandwidth uploading just the diff.gz to the bug report ;)
[00:15] <devfil> pochu: I know, but I prefered this solution to have the orig.tar.gz with the good md5 etc...
[00:15] <pochu> ah, right
[00:16] <pochu> oh, let dato know about it, in case he uploads to Debian, so we have the same tarball and can sync in the future
[00:16] <devfil> now orig.tar.gz generated by get-orig-rules had the same md5 for each launch of rule
[00:16] <pochu> that's great
[00:16] <devfil> pochu: yes sure
[00:16] <devfil> I prefer firstly a review to see if it is ok
[00:17] <devfil> s/a/to have a/
[00:18] <pochu> but tomorrow :)
[00:18] <pochu> good night
[00:18] <devfil> good night
[00:48] <lifeless> Hobbsee: did I see you mention something about pidgin the other day?
[01:25] <RainCT> good night
[01:27] <ApOgEE-> hi
[02:44] <nxvl> ScottK: around?
[02:44] <tacone> nxvl: may I contact you in prv ?
[02:45] <nxvl> well
[02:45] <nxvl> ok
[02:45] <nxvl> :D
[02:45] <nxvl> if you have something prv to day
[02:45] <nxvl> say*
[02:46] <tacone> lots :-)
[02:46] <emgent> if you like feel free to use rapache-devel for this
[03:06] <Hobbsee> lifeless: w.r.t?
[03:06] <lifeless> out of date client or something
[03:06] <ajmitch> probably the icq mess
[03:06] <Hobbsee> lifeless: oh yeah - icq being annoying again.
[03:06] <lifeless> ajmitch: sounds like I'm hitting it :)
[03:07] <lifeless> whats the story?
[03:07] <Hobbsee> lifeless: they've pushed an update into proposed, afaik.
[03:07] <Hobbsee> lifeless: every once in a while, icq decides that the old clients are too old, and won't let them connect.
[03:07] <lifeless> with no other changes?
[03:07] <Hobbsee> so every once in a while, we have to bump the ICQ version string on the clients.
[03:07] <Hobbsee> yup.
[03:07] <lifeless> spethial
[03:07] <Hobbsee> well, presumably there's changes to the official clients, but not to us
[03:07] <Hobbsee> yes, very...
[03:08] <ajmitch> changes probably means more advertising on the official clients
[03:08] <Hobbsee> ajmitch: very likely.
[03:08] <lifeless> can't pidgin just try a few new numbers and see if one works?
[03:08] <Hobbsee> good question - i'm only familiar with the kde3 kopete side
[03:09] <persia> lifeless: kopete does something similar: if it fails to log in, it grabs the newest version codes from the net, and tries with those.
[03:09] <Hobbsee> but i think that's what the kde4 version is doing - auto-updating
[03:09] <persia> Hobbsee: Isn't it only auto-updating the ICQ version information, rather than the whole application?
[03:10] <Hobbsee> persia: yes, taht's what i meant, sorry
[03:11] <persia> Hobbsee: No need to be sorry: I just wanted to make sure I had the right story.  Thanks for the confirmation :)
[03:12] <emgent> hello people
[03:15] <Hobbsee> persia: no problem
[03:16]  * TheMuso wonders what bitlbee does then, since I'm having no problems.
[03:17] <persia> TheMuso: If you find out, could you port to the others?
[03:17] <TheMuso> persia: Perhaps, but I have no reason to dig unless it breaks. :p
[03:18] <persia> Right.  Maybe someone ought put a pointer to using BitlBee as a proxy in the pidgin bug :)
[03:54] <nxvl> ok
[03:54] <nxvl> i think augeas has the correct copyright now
[03:54] <nxvl> :D
[03:55] <persia> nxvl: You've checked every single file?
[03:56] <nxvl> yep
[03:56] <nxvl> not only the *.c files
[03:56] <nxvl> also the .m4 ones
[03:56]  * persia uses `less $(find .)`
[03:57] <persia> nxvl: And the other files?  No .h?  No .xml?  Nothing else?
[03:57] <nxvl> i used: find . -name '*.*' | xargs head | less
[03:57] <ajmitch> my head hurts from reading mail about voting methods
[03:57] <persia> nxvl: Be careful.  Sometimes people put extra licensing conditions and the like below the first 10 lines.
[03:58] <nxvl> i'm using .c and .h has same licenses
[03:58] <nxvl> s/using/asuming/g
[03:59] <persia> That's not safe.  The .h files might be more open (e.g. ISC vs. GPL) for a common interface, or more tightly restricted where compatibility with some specific implemenation is required.
[03:59] <nxvl> well, the only !LGPL are the tools used for building and things, and almost all of them are from GNU
[03:59]  * nxvl checks .h files
[03:59] <persia> nxvl: As long as you're sure :)
[04:00] <nxvl> yes, i am
[04:00] <persia> Also, $(find .) is the same as $(find -name "*.*"), except that it also matches e.g. README (where there is no '.')
[04:00] <nxvl> but a quick look doesn't hurt, don't it?
[04:00] <persia> Never :)
[04:01] <nxvl> well
[04:01] <nxvl> i have read README files carefully
[04:01] <nxvl> as well as all the non source files
[04:06] <nxvl> ok
[04:06] <nxvl> rechecked
[04:11] <nxvl> now i'm sure it's correct
[04:17] <persia> nxvl: Perfect!
[05:19] <null_vector> if a patch closes duplicate bugs how do you show that in the changelog? (LP:XXX)(LP:XXX)?
[05:19] <persia> null_vector: Do you mean two different bugs, or are the bugs themselves duplicate?
[05:20] <null_vector> they're dupes
[05:21] <persia> null_vector: Close the master.  Make sure the duplicate is appropriately marked as a duplicate in launchpad.
[05:25] <ScottK> nxvl: I'm around for a bit now.
[05:25] <nxvl> about the revu comments
[05:25] <nxvl> NEWS didn't install when installing dh_installdocs is runned
[05:26] <nxvl> but it's also not required so i remove it
[05:26] <ScottK> nxvl: If it doesn't install automatically, ignore my comment.
[05:26] <ScottK> I thought it did.
[05:26] <ScottK> Sorry about that.
[05:26] <nxvl> also it has informatios about gnulib's license
[05:26] <ScottK> It should be installed.
[05:26] <nxvl> well, no problem
[05:26] <nxvl> :D
[05:26] <nxvl> every single comment is valid
[05:26] <nxvl> they make me learn and investigate new things
[05:42] <dholbach> good morning
[06:01] <AstralJava> Morning dholbach!
[06:01] <dholbach> hi AstralJava
[06:03] <AstralJava> dholbach: How's life? You're up awfully early. :)
[06:37] <dholbach> AstralJava: life is good - I'm quite busy with stuff, but will leave for holidays in around a week - how are you?
[06:38] <nxvl> dholbach: you woke up really early today
[06:39] <AstralJava> dholbach: Fine, thanks. One and a half weeks till holiday, but I'll manage. Getting around some packaging and merge stuff again. Won't mention anything about the progress of my MOTU voyage, though, as I'm sure you've noticed also it takes a considerable amount of time... :D
[06:39] <dholbach> I almost wake up at that time - it's summer, my girlfriend has to get up early for work, so....
[06:39] <nxvl> heh
[06:39] <nxvl> :D
[06:39] <nxvl> here it's winter
[06:51] <\sh> ScottK: nope...but I'll check on it :)
[06:59] <ScottK> \sh: I thought you might find it interesting.
[07:05] <\sh> let's see..what comes after all launchpad features :)
[07:06] <\sh> right now I'm planning on offline storage of the lp tasks into a sqlite db
[07:24] <slytherin> any archive admins around?
[07:25] <dholbach> slytherin: #ubuntu-devel might be a better choice
[07:25] <persia> slytherin: Rarely in this channel.  Try #ubuntu-devel
[08:15] <slytherin> What is failed to upload error for a build?
[08:20] <dholbach> Laney, geser: interview publichsed
[08:20] <dholbach> published
[08:20]  * dholbach gets more coffee
[08:21] <persia> slytherin: It typically indicates some issue with bits of Soyuz speaking with each other.  I'd recommend asking someone to investigate on #launchpad.
[08:38] <gnomefreak> anyone else having no sound in Intrepid? i enabled everything but stil no sound
[08:42] <persia> gnomefreak: cat /proc/asound/cards  Notice the new device.  Change your default.  Ask Hobbsee for details :)
[08:42] <persia> In other news, you can now make your case warble whilst not interrupting your audio stream :)
[08:48] <gnomefreak> Hobbsee: what would i need to do to get sound working in intrepid?
[08:56] <abogani> Hi MOTUs!
[08:56] <abogani> Could Someone review my package on REVU please?
[08:56] <abogani> The packages is rt-tests (http://revu.ubuntuwire.com/details.py?package=rt-tests): A set of programs that test and measure various components of "realtime" kernel behavior, such as timer latency, signal latency and the functioning of priority-inheritance mutexes.
[08:56] <abogani> Please be patient with me it's my first package. :-)
[08:56] <abogani> Thanks in advance!
[08:57] <directhex> sounds neat
[09:07] <persia> abogani: Quick notes: 1) some of my points from January still stand, 2) You should target intrepid rather than hardy, 3) It's a new package, so still Initial release, 4) My lintian says policy is 3.8.0
[09:07] <cody-somerville> ScottK, poke
[09:08] <dholbach> cody-somerville: he went to bed an hour ago
[09:09] <cody-somerville> :(
[09:09] <dholbach> Guys... it's sponsoring time!
[09:09] <abogani> persia: Ok Thank you a lot!
[09:09] <cody-somerville> :)
[09:17] <persia> Right.  As this thread goes further, I get convinced of the benefits of the one-person, one-vote system.  We just need the right person.
[09:17] <directhex> that reminds me, i was gonna work on some packaging this morning
[09:18] <directhex> bleh, new packages means NEW delay
[09:18] <bliZZardz> persia : i plan to do some packaging this weekend. Are new packages being considered for Interpid?
[09:18] <persia> directhex: NEW delay isn't as bad when fear-of-NEW delay is short :)
[09:19] <persia> bliZZardz: Yep.  Look for needs-packaging bugs in LP for candidates.
[09:20] <bliZZardz> persia: i was more ref to those which are not even present there - will those be considered now? or is it better to concentrate on 'needs-packaging' ?
[09:21] <directhex> i need to start beating my DD contact with a bigger pole, or start considering a 0ubuntu1 package
[09:21] <persia> bliZZardz: Things with needs-packaging are user requests.  If you want something else, you need to put on your user hat, and make a request :)
[09:22] <bliZZardz> persia : follow up Q to the previous, should i also consider backporting the packages that i target for Interpid?
[09:22] <bliZZardz> or simply i can take it up later
[09:22] <persia> bliZZardz: Anything present in intrepid is potentially available to be backported.
[09:27] <directhex> not anything.
[09:27] <directhex> "frameworks" are excluded, for example
[09:29] <bliZZardz>  persia: i do not understand when you say 'potentially available to be backported'
[09:30] <persia> directhex: I doubt it: I suspect that if you had a framework that was a development target with no dependencies in the archive, it could be backported.
[09:30] <persia> bliZZardz: A request for backporting may be made for any package in the current development archive.
[09:31] <directhex> well, yeah, dependencies is the problem. the cited reason being risk of regression in too many apps, iirc
[09:31] <persia> You do.
[09:35] <directhex> sigh, this is my most complex packaging work so far. time to learn, fast.
[09:43] <enyc> hrrm. Is  ubuntu 8.04.1  releasing today?
[09:43] <persia> enyc: There's testing.  For current results (which would inform the release manager), you may want to ask in #ubuntu-testing.
[09:45] <enyc> persia: ok I shall go look /ask ;-)
[09:45] <enyc> persia: and report my findings etc... thanks for channel pointer ;-)
[09:53] <devfil> persia: ping
[09:54] <YokoZar> ScottK: Wine 1.0 has been in backports for some time, and no bugs filed yet...Would it be appropriate to move it to -proposed now?
[09:55] <persia> devfil: It's *always* better to explain why you want someone.  I suspect that regardless of your question, someone else here will be better able to answer it, but I'm here now: what are you asking?
[09:55] <devfil> persia: http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8
[09:56] <devfil> if you want to take a look at it
[09:56] <persia> devfil: Right.  You do know that I don't use *any* wx2.87 apps, right?
[09:56] <persia> I'll add it to my review list.
[09:56] <persia> s/7//
[09:57] <devfil> persia: but you know the package and for me you are the best to check for soname etc...
[09:58] <persia> devfil: I'll review it.  I'll also note that the only reason I know wx is because I was trying to purge an old version: it is familiarity through revulsion, rather than because I like the package :)
[10:00]  * sebner waves :)
[10:01]  * DktrKranz plans revenge
[10:01]  * sebner hides
[10:07]  * DktrKranz notes wxwidgets2.8 is finally in unstable, we should work closely with dato to have it finally in sync
[10:18] <slytherin> persia: DO you have time to advocate xml-commons-external? If it goes in archive today then I will be able to complete batik upgrade today itself.
[10:19] <persia> slytherin: What does it need?
[10:20] <slytherin> persia: I need seond advocate for my package on revu. geser has already advocated.
[10:27] <slytherin> persia: for some reason the package is neither on revu nor in archive
[10:28] <persia> slytherin: You'll want to put it in one of those places if I'm going to look at it :)
[10:28] <slytherin> persia: it was there on revu till 2 days ago.
[10:31] <persia> slytherin: http://revu.ubuntuwire.com/details.py?package=xml-commons-external and https://launchpad.net/ubuntu/intrepid/+queue?queue_state=0&queue_text=xml-commons-external should explain the current status.
[10:31] <slytherin> persia: someone already gave second opinion. It is being uploaded.
[10:31] <Laibsch> good morning
[10:32] <Laibsch> How do I use "bzr bd" with pbuilder to build a package (for upload to a ppa)
[10:32] <Laibsch> ?
[10:32] <slytherin> persia: Cool. I will hopefully have batik updated and uploaded to review by tonight.
[10:34] <persia> slytherin: Note that until xml-commons-external passes both source new and binary new, batik is likely to FTBFS.
[10:35] <slytherin> persia: That is fine. The package review will take time. I will add a note on revu saying it needs xml-commons-external.
[10:43] <james_w> Laibsch: you want to use the "--builder" option to bd
[10:43] <Laibsch> james_w: Thanks.  I'll give it a try
[10:43] <james_w> Laibsch: e.g. "bzr bd --builder pdebuild"
[10:43] <Laibsch> I did not see it in the man page
[10:43] <Laibsch> OK
[10:43] <persia> james_w: Does that work with sbuild as well?
[10:43] <james_w> Laibsch: or, what I do, which is "bzr bd -S" and then use pbuilder-dist on the resulting source.
[10:44] <Laibsch> That sounds good.
[10:44] <Laibsch> I tried -S, but then failed to sign the packages
[10:44] <Laibsch> s/packages/files/
[10:44] <james_w> persia: it requires a builder that works from inside an unpacked source package, like dpkg-buildpackage does. I'm not familiar with sbuild.
[10:44] <Laibsch> .changes etc
[10:44] <persia> Laibsch: debsign can help with that.
[10:45] <persia> james_w: Ah.  sbuild acts on prepared source packages.  I suspect bd -S is the appropriate workflow for sbuild users (and likely also for most pbuilder users if they expect to get the results into Ubuntu)
[10:45] <james_w> yup
[10:47] <slytherin> Laibsch: What error does it give when trying to sign package?
[10:47] <DktrKranz> doko: re bug 218963, SRU FTBFSed. If you want, I can have a look at it
[10:49] <Laibsch> slytherin: no particular error
[10:49] <doko> DktrKranz: no need, there is a fix in the upload queue
[10:49] <Laibsch> I just did not get what I needed
[10:49] <Laibsch> I am not even sure, I used debsign
[10:49] <slytherin> Laibsch: not sure if it is related but I usually use options -S -sa
[10:50] <DktrKranz> doko: ah... noticed just now. sorry.
[10:52] <StevenK> w
[10:52] <StevenK> Oops
[11:02] <slytherin> is anyone able to do proepr session recording with istanbul?
[11:22] <directhex> right, i think i'm done working on this package
[12:07] <Laney> dholbach: Woohoo!
[12:07] <raphink> :)
[12:12] <emgent_> morning
[12:13] <Laney> howdy emgent_
[12:14] <sistpoty|work> hi folks
[12:17] <emgent> hey sistpoty|work
[12:17] <sistpoty|work> hi emgent
[12:20] <Iulian> Hello emgent, sistpoty
[12:20] <sistpoty|work> hi Iulian
[12:20] <emgent> hi Iulian
[12:21] <Laney> How's life all?
[12:24] <cody-somerville> Did we ever agree on any standards for DIF exceptions/acks?
[12:25] <persia> cody-somerville: We did, but I hadn't sent out the minutes.  I'll write them up now.
[12:25] <cody-somerville> persia, Thanks. I was thinking of tackling the sponsor queue :)
[12:25] <slytherin> persia: is geser aware of java team meeting today?
[12:25] <persia> http://irclogs.ubuntu.com/2008/06/27/%23ubuntu-meeting.html has the log if you're curious
[12:26] <persia> slytherin: I don't have private information, but I suspect the answer will soon be: "Yes" :)
[12:28] <RainCT> is come bored core dev around? :P
[12:28] <RainCT> *some even
[12:29]  * sistpoty|work is around, but not bored *g*
[12:29] <cody-somerville> sebner, ping
[12:33] <cody-somerville> Are we setting ACKed sync requests as triaged or confirmed?
[12:33] <Hobbsee>  either
[12:34] <RainCT> sistpoty|work: there's the first debdiff from my mentee waiting at #68852, if you want to have a look at it :P
[12:34] <RainCT> bug #68852
[12:36] <sistpoty|work> RainCT: on a first glimpse, looks good. but as I'm at work I cannot build packages here...
[12:36] <cody-somerville> Does anyone know how to unsubscribe with the new launchpad UI?
[12:37] <sistpoty|work> RainCT: if it's not uploaded this evening, I'll give it a closer look then ;)
[12:37] <RainCT> cody-somerville: click on 'yourself'
[12:37] <RainCT> sistpoty|work: okay, thanks :)
[12:37] <Laney> cody-somerville: When it's a red - symbol, it will unsubscribe
[12:37]  * Hobbsee wonders what sharm's regular nick now is?
[12:40] <sebner> cody-somerville: pong
[12:40] <cody-somerville> sebner, when you file sync requests can you please be more verbose then just pasting the debian changelog?
[12:41] <sebner> cody-somerville: once an archive admin told me I shouldn't write more text since it will take them more time to read and check if it's ok O_o
[12:42] <RainCT> lol
[12:42] <cody-somerville> sebner, Do you remember which particular archive admin said that?
[12:43] <sebner> It confuses them
[12:43] <sebner> cody-somerville: though I'm a universe-contributor so you could trust me xD
[12:43] <sebner> cody-somerville: buh long ago. I'll check my bug reports
[12:43] <Hobbsee> ....that's oh so wrong, on oh so many levels...
[12:43] <sebner> Hobbsee: hmm?
[12:44] <persia> sebner: Please do provide some information including 1) Why any Ubuntu variation can be dropped, 2) what is good in the new version, and 3) whether it compiles & runs under the current development target.
[12:44] <Hobbsee> [21:41] <sebner> cody-somerville: once an archive admin told me I shouldn't write more text since it will take them more time to read and check if it's ok O_o
[12:44] <persia> Even if the archive admins ignore it, it helps the rest of us understand why something was pulled or overwritten.
[12:45] <Hobbsee> archive admins shouldn't be checking if it's correct anyway
[12:45] <RainCT> sebner: bah, I don't trust you anymore :P
[12:45] <Hobbsee> that's the job of the sponsor, or the MOTU.
[12:45] <sebner> persia: well the syncs I filed are real since and they were syncs in the past so nothing to drop, I testbuild everything so the only thing is to write why I sync the new version
[12:45] <Hobbsee> and if they can't get that right, they clearly should not be sponsoring / requesting a sync for that particular package.
[12:46] <Hobbsee> sebner: were you filing sync requests while the autosync was still on?
[12:46] <sebner> Hobbsee: nope
[12:46] <Hobbsee> hm
[12:46] <cody-somerville> sebner, Even if there is no Ubuntu delta, you should mention that.
[12:46] <persia> sebner: You write the rationale for the sync and the new Debian changelog?
[12:46] <sebner> Hobbsee: btw, why was the auto-syncs going crazy yesterday?
[12:46] <Hobbsee> sebner: it should be off, so i've no idea.
[12:46] <sebner> persia: not the rationale ;\
[12:46]  * Hobbsee does not have access to it.
[12:47] <sebner> cody-somerville: exactly that was the complain by a archive admin
[12:47] <persia> sebner: I think the rationale is the most important part: why should we sync?  Post DIF, we ought have some reason, and pre-DIF all non-auto syncs are overwriting Ubuntu variation.
[12:48] <cody-somerville> sebner, Well, if you tell us his or her name we can send Hobbsee after them : P
[12:48] <cody-somerville> In the mean time, please follow the sync procedure.
[12:48] <Laney> I just use the requestsync tool from ubuntu-dev-tools, which tells you to put a rationale in
[12:48] <sebner> cody-somerville: kk, /me becomes too sloppy filing syncs (like motu') :P
[12:48] <cody-somerville> ;]
[12:49] <sebner> persia: shouldn't the u-u-c be somehow more trustful than a normal contributor? Besides you are right writing the reason why to sync
[12:49] <persia> sebner: Being sloppy about syncs is not ideal, regardless of which groups might accept one as a member
[12:50] <persia> sebner: It's not about trust: it's about documentation for people investigating things later.
[12:50]  * cody-somerville nods.
[12:51] <sebner> persia: how big are my chances to get an ACK when I write: "Shiny new upstream version and still enough time to fix potential bugs" ?
[12:51] <persia> sebner: low.
[12:52] <sebner> persia: that was my work for hardy cycle. you should sponsor/complain more :P
[12:52] <persia> How about "New upstream provides features X, Y, and Z.  No new dependencies.  Compiles cleanly on intrepid, and runs well in Kubuntu".
[12:52] <sebner> persia: ok that's the long version of my sentence ^^
[12:52] <persia> sebner: Most of your stuff I saw in the hardy cycle had enough documentation that I could understand the reason for it.
[12:53]  * sebner can't remember
[12:53] <geser> slytherin: I've seen the announcement for the java team meeting, perhaps I'll attend
[12:53] <persia> Yep.  Being just a little wordier than "shiny new upstream: please sync" is all that is required :)
[12:53] <RainCT> sebner: hey, my comment was serious :P
[12:53] <sebner> RainCT: hrhr
[12:54] <sebner> persia: kay, will do in future. just a side-notice. (some) motu's are writing: Dear archive admins please sync + changelog ....
[12:54] <cody-somerville> sebner, and if you file sync requests on packages that are related you should probably mention if they need to be synced together or not.
[12:54] <sebner> cody-somerville: refer to sauerbraten or simutrans?
[12:54] <cody-somerville> maybe.
[12:55] <sebner> didn't know that they can do that =)
[12:55] <cody-somerville> sebner, well, I don't want to approve one and not the other if it'll cause breakage.
[12:55] <persia> sebner: I don't like that behaviour from anyone, regardless of who.  Feel free to complain to them if you don't understand why something is a sync.
[12:57] <sebner> persia: I look at the changelog and the last ubuntu version and see why it is a sync so I don't mind. it's just, I already told you, that MOTU can do what they want and no one cares and a contributor always get complains (which are mostly good)
[12:58] <persia> sebner: MOTU also get complaints.  As I said, please complain if you see inappropriate behavious.
[12:58] <persia> s/s.$/r./
[12:59] <sebner> persia: the problem is that it don't disturbe me so I would have to complain for others/the rules
[12:59] <persia> sebner: OK.  Please spend more time tracking down regression bugs, and develop a new opinion.
[13:00] <ScottK> cody-somerville: I'm awake now.
[13:00] <sebner> persia: kay. Besides I will start packaging things from scratch now so I won't file mass syncs again ;)
[13:01] <ScottK> YokoZar: How about you file a bug against WINE to get moved and then ask for positive/negative comments there.  Once we have some good story, then we do it.
[13:06] <emgent> rapache 0.4 is out with apache2 modules support
[13:06] <cody-somerville> ScottK, :)
[13:09] <ScottK> cody-somerville: I got ~ 4 hours of sleep last night, so I may not be entirely coherent.
[13:09] <cody-somerville> ScottK, To be honest, I didn't sleep at all.
[13:09] <ScottK> cody-somerville: I think the biggest advantage for condorcet is the one you pointed out about not dropping candidates early and so getting a good compromise candidate.
[13:09] <Laney> We need a ubuntu-dev-keyring package, methinks
[13:10] <ScottK> I don't think it matters that it's more complex.  I don't see any other downsides.
[13:10] <ScottK> Laney: What for?
[13:10] <ScottK> For who-uploads?
[13:10] <Laney> ScottK: For when I dget -x something, I hardly ever have the key so have to do another dpkg-source step
[13:11] <Laney> Yes, I could do xu, but it's nice to verify anyway
[13:11] <ScottK> Laney: It'd probably be easy enough to script out of LP.
[13:13] <Laney> I might look into doing it
[13:17] <null_vector> morning
[13:25] <glatzor> hello dholbach, I created the ubuntu-translator-tools package which contains little helpers for translators: firefox search for rosetta, podiff (compares po files), search-translation (allows to search for strings in the locally installed language packs) and enables the ppa with the automatic updates language-packs
[13:25] <glatzor> dholbach, the ppa is at https://edge.launchpad.net/~ubuntu-translator-tools-hackers/+archive
[13:26] <glatzor> dholbach, perhaps it is worth to add it to universe
[13:26] <glatzor> dholbach, the ppa also includes python-polib which is required by podiff
[13:29] <glatzor> dholbach, oh, but I would have to update it for intrepid before.
[13:42] <Laibsch> How does one merge branches in LP?  Just pull the two branches, push the obsolete to the new branch and delete the obsolete branch?
[13:43] <Laibsch> I am talking about https://code.launchpad.net/~vcs-imports/subdownloader/trunk for example
[13:44] <null_vector> what's the other branch?
[13:44] <Laney> Yay, my first SRU is published \o/
[13:45] <DktrKranz> Laney: welcome in the club :)
[13:45] <Laney> Thanks DktrKranz!
[13:45] <DktrKranz> once started, it's hard to come back
[13:47] <dholbach> glatzor: sounds good - best to get it on REVU and get it reviewed
[13:49] <glatzor> dholbach, I am just reading the howto
[13:49] <dholbach> great
[13:49] <glatzor> would you like to add me to uploaders team?
[13:49] <glatzor> or is there a special requirements
[13:50] <james_w> hey glatzor
[13:50] <glatzor> hello james_w !
[13:51] <glatzor> ok, I should have taken a look a before :)
[13:52] <glatzor> ajmitch, hi, would you please sync the revu-upload keyring?
[13:52] <sistpoty|work> glatzor: sync is already in progress ;)
[13:52] <glatzor> thanks sistpoty|work
[13:52] <sistpoty|work> np
[13:53] <persia> And I was all ready and waiting this time.  I will get it one of these times...
[13:54] <sistpoty|work> sorry persia ;)
[13:58] <persia> sistpoty|work: No need to be sorry: you should celebrate your response speed :)
[13:59] <sistpoty|work> persia: well, I guess my fast response speed also means that I'm once again procrastinating *g*
[14:00] <sistpoty|work> glatzor: done
[14:02] <null_vector> ls
[14:09] <joshu> Where do i file a version bump for an applicatien?
[14:09] <joshu> I'd like to get an application updated.
[14:10] <sistpoty|work> joshu: file a wishlist bug against the package
[14:10] <RainCT> joshu: new bug on https://bugs.launchpad.net/ubuntu/+source/<source package name>, and tag it "upgrade"
[14:11] <joshu> RainCT: Thank you.
[14:16] <Laibsch> null_vector: The other branch is https://code.launchpad.net/~subdownloader-developers/subdownloader/trunk
[14:16] <slytherin> joshu: before filing bug make sure that version is not there already in intrepid
[14:16] <Laibsch> I guess my question is who is supposed to act on the "please merge this branch" flag
[14:18] <persia> Laibsch: The owner of the branch requested to perform the merge.
[14:20] <Laibsch> hm, not really
[14:20] <Laibsch> I did
[14:20] <persia> Laibsch: Maybe ask in #launchpad?  They usually understand the correct UI better than we.
[14:21] <Laibsch> OK
[14:41] <Laney> If I want to deal with the NBS of this library (http://people.ubuntu.com/~ubuntu-archive/NBS/libopenbabel2), will it just be enough to file bugs for a rebuild?
[14:42] <Laney> (after b/i/r testing of course)
[14:44] <geser> Laney: yes, if it builds with the new library version
[14:44] <Laney> geser: Cool, will do
[14:44] <Laney> Just check that it deps on openbabel3 after the build
[14:45] <geser> Laney: please also check if there are easy bugs to be fixed for those packages
[14:45]  * Laney nods, will do
[15:47] <azeem> Laney: libopenbabel3 rebuilds should probably wait till the weekend, the final 2.2 release is due tomorrow, and there's currently still discussions on what the library version should be
[15:48] <Laney> azeem: Oh right, thanks for letting me know
[17:09] <jmehdi> Hi, can someone review my package update on REVU? http://revu.ubuntuwire.com/details.py?package=webstrict
[17:09]  * sistpoty|work heads home... cya
[17:22] <sebner> dholbach: standard-version should be 3.8.0 but besides it's a nice vid ;)
[17:22] <dholbach> sebner: it was shot, when there was no 3.8.0 yet
[17:23] <sebner> kay
[17:46] <amikrop> In debian/control, do the Depends and Build-Depends fields, get filled automatically (and correct)?
[17:46] <bddebian> Heya gang
[17:46] <ScottK> amikrop: No.
[17:47] <amikrop> ScottK: But what about some ${foo:Depends}?
[17:47] <ScottK> For some cases that works, but not all and it's not for build-dep.
[17:57] <Festor> ScottK, I could upload (at least send the diff.gz file) of amsn 0.97.1 to Intrepid? I added 2 patches
[17:58] <Festor> and I want test
[17:58] <Festor> or I should wait to next bugfix release of amsn?
[17:59] <Festor> I say that for this:
[17:59] <Festor> https://bugs.launchpad.net/ubuntu/+source/amsn/+bug/244876/comments/6
[18:00] <ScottK> Festor: I'd discuss it with cody-somerville or bigon.  They've both done recent uploads of the package.
[18:00] <Festor> ok
[18:03] <Festor> I want insert this plugin in amsn package:
[18:03] <Festor> http://www.amsn-project.net/plugins.php#5
[18:03] <Festor> I made all work
[18:03] <Festor> and I have ready the patch but I need make diff.gz file
[18:03] <Festor> also
[18:04] <Festor> there is https://bugs.launchpad.net/ubuntu/+source/amsn/+bug/99605
[18:05] <Festor> and for this
[18:05] <Festor> https://bugs.launchpad.net/ubuntu/+source/amsn/+bug/40907
[18:06] <Festor> Is it possible to update your version of aMSN?
[18:06] <Festor> or we should use patches?
[18:07] <persia> Festor: Best to update for intrepid, and use patches for older versions.  Check with those most recently in the changelog for closer guidance.
[18:09] <Festor> ok, but 0.95 of dapper is too old
[18:10] <Festor> hi jpds
[18:10] <jpds> hi Festor
[18:11] <pochu> Festor: 0.97 could be considered for dapper-backports, but not for dapper-updates as it's not bug-fix only, but contains several new features
[18:12] <pochu> if there's any specific patch you want to consider, that's different
[18:14] <Festor> the problem, pochu is that it is no easy make a patch for a too old version
[18:15] <Festor> because I dont know what release fix the bug
[18:15] <persia> Festor: What about it doesn't work?  Protocol?  Version identification check?
[18:15] <Festor> wahttps://bugs.launchpad.net/ubuntu/+source/amsn/+bug/40907
[18:15] <Festor> https://bugs.launchpad.net/ubuntu/+source/amsn/+bug/40907
[18:16] <Festor> "The servers at Microsoft were upgraded and no longer allow connections via port 80. They have decided that all connections must use SSL."
[18:16] <Festor> this is protocol?
[18:18] <pochu> Festor: I think so
[18:18] <persia> Festor: That's protocol, and likely fairly easy.
[18:18] <persia> Just review the upstream changelog to verify that SSL support exists in 0.95, and submit a patch to use that SSL support by default.
[18:18] <pochu> I've just connected with emesene through http
[18:18] <pochu> and not https
[18:19] <persia> If there is no such support, it ought be easy to extract, and then link against the right SSL libraries.
[18:19] <Festor> pochu, this is in dapper
[18:19] <pochu> but you quoted this:
[18:19] <pochu> 19:16 <    Festor> "The servers at Microsoft were upgraded and no longer allow connections via port 80. They have decided that all connections must use SSL."
[18:19] <pochu> which either is wrong or is incomplete
[18:20] <Festor> but 2 users confirm the bug
[18:20] <ScottK> Probably they confirm they can't connect, not the root cause.
[18:21] <Festor> I should change report to invalid?
[18:21] <ScottK> No, just don't assume the reported cause is correct.
[18:21] <Festor> ok
[18:21] <ScottK> The problem, can't connect, is presumably right.
[18:21] <ScottK> So it's a valid bug.
[18:22] <Festor> ScottK, and what about this https://bugs.launchpad.net/ubuntu/+source/amsn/+bug/99605 ?
[18:22] <ScottK> A bug triager who was interested (i.e. not me) might ask for more information to figure out why.
[18:22] <ScottK> Festor: I'm one of 6 people that mind proposed updates to an archive of 20,000 packages.  I can't sort through each one.
[18:24] <Ash-Fox> Which was the last version of ubuntu that didn't have stack protections in libc?
[18:25] <Festor> Sorry ScottK , I refer to this patch http://launchpadlibrarian.net/15787915/08_use_aplay_for_sound.dpatch
[18:25] <Festor> I think that fixes the bug
[18:26] <ScottK> Test it first and then we can talk.
[18:26] <Festor> I have this patch working now
[18:26] <Festor> I there is no problme
[18:27] <Festor> only changes play for aplay
[18:27] <Festor> to use ALSA
[18:27] <ScottK> cody-somerville: You around?
[18:27] <cody-somerville> ScottK, yup
[18:28] <ScottK> cody-somerville: Can you look at Festor's amsn patch?  You're a lot more familiar with the package than I am.
[18:29] <cody-somerville> Sure.
[18:29] <Festor> thanks! :D
[18:29] <cody-somerville> Festor, Do you have a debdiff?
[18:30] <Festor> now no
[18:30] <Festor> I should have one?
[18:31] <cody-somerville> Festor, Okay, look at your patch, what makes you think that that it'll affect already existing profiles?
[18:31] <Festor> for already no
[18:32] <Festor> for all are made after the update
[18:32] <Festor> I think
[18:32] <cody-somerville> Also ,it appears that nire was having the same mixing problem with aplay.
[18:32] <cody-somerville> Has the situation changed?
[18:32] <Festor> 	
[18:32] <Festor> I think that when amsn create a profile takes the default options
[18:33] <cody-somerville> Right so it won't affect people who have already ran aMSN - only people who would install it after your SRU
[18:33] <Festor> ehh, sorry "Solution: aplay should be used instead of play."
[18:33] <Festor> of https://bugs.launchpad.net/ubuntu/+source/amsn/+bug/99605
[18:33] <Festor> and I use aplay now
[18:33] <Festor> and www.ubuntu-es.org
[18:33] <Festor> suggest use aplay
[18:33] <Festor> cody-somerville, yes
[18:33] <cody-somerville> Festor, I'm reading the bug report and nire reports the *same* problems with aplay.
[18:34] <cody-somerville> Festor, so why do you think it'll work now?
[18:34] <Festor> but but something is something
[18:34] <Festor> I should repet all that I wrote before?
[18:34] <Festor> sorry for my bad English
[18:34] <Festor> :(
[18:35] <Festor> cody-somerville, We should use alsa always, no?
[18:35] <Festor> and where is the problem?
[18:36] <Festor> play command does not exist in Ubuntu
[18:37] <cody-somerville> Festor, If making the change doesn't fix the alleged problem then why make the change?
[18:38] <cody-somerville> (in terms of a stable release update)
[18:39] <Festor> 	
[18:39] <Festor> Do not solve the existing problem, but when a new user installs the amsn will not have the problem
[18:39] <Festor> Its the same as xdg patch
[18:39] <Festor> I think that when amsn create a profile takes the default options
[18:39] <Festor> then all users without this update
[18:39] <Festor> have the problem
[18:40] <Festor> but new user will not
[18:40] <AstralJava> Festor: play command exists, if you install sox.
[18:41] <cody-somerville> Okay.
[18:42] <cody-somerville> So you're not actually trying to fix *that* specific bug.
[18:42] <Festor> Ash-Fox, for default sox is not installed
[18:42] <Festor> cody-somerville, That is not possible
[18:43] <Festor> For this we should change the profile of each user of amsn
[18:45] <Pici> I'm only sort of following this, but changing the profile of each user is a bit out of the question, why not just add sox as a new dependency or similar to the package?
[18:45] <Festor> That does not ensure that works
[18:45] <Festor> but aplay yes
[18:46] <Festor> from ubuntu-es.org
[18:46] <Festor> http://doc.ubuntu-es.org/Preguntas_de_uso_frecuente#Mi_aMSN_no_emite_sonidos._.C2.BFC.C3.B3mo_puedo_solucionarlo.3F
[18:46] <Festor> it is in spanish but is understand
[18:47] <pochu> perhaps amsn should just depend on sox, it doesn't yet
[18:47] <cody-somerville> It doesn't qualify under debian policy to be a depend, does it?
[18:49] <cody-somerville> However, doing that would be better than modifying the default config to use aplay
[18:50] <Festor> sorry but this is not the same case as "- Use xdg-open for file manager, and opening files - not just browser."
[18:50] <persia> Is sox already in Recommends: ?  It may just be a manifestation of not installing Recommends:
[18:50] <Festor> 	
[18:50] <Festor> aMSN calls for a program that does not exist or is not installed
[18:50] <cody-somerville> persia, It is a suggest
[18:51] <Festor> and in this case, you use xdg-open
[18:51] <cody-somerville> Festor, But I wasn't doing an SRU
[18:51] <Festor> and what?
[18:51] <Festor> there is the same problem
[18:52] <cody-somerville> Festor, Yes and I'd be happy to sponsor your upload for Intrepid.
[18:52] <persia> If the default config expects it, I'd argue Recommends: is more correct.
[18:52] <cody-somerville> persia, Thats what I was thinking
[18:53] <pochu> according to http://packages.ubuntu.com/dapper/amsn it depends on sox
[18:54] <pochu> (in dapper)
[18:54] <Festor> in hardy no
[18:54] <pochu> but we are talking about dapper, aren't we?
[18:54] <pochu> or is hardy also affected?
[18:54] <Festor> at least I
[18:54] <Pici> Looks like it was moved to a suggests for Gutsy.
[18:54] <Festor> I talking about hardy
[18:54] <Festor> and gutsy
[18:54] <pochu> ah, ok
[18:55] <pochu> so does installing sox solve it?
[18:55] <Festor> I dont know
[18:55] <persia> Why was it moved to suggests?  Somehow I'd think that change ought be associated with a config change (which is hard, and violates policy)
[18:56] <pochu>   * Moved sox and docker from Depends to Suggests.
[18:56] <pochu> nothing else in debian/changelog
[18:56] <persia> See, that's not very informative :(
[18:57] <persia> Should close a bug or provide an explanation, else we don't understand what happened, and nobody is likely to remember anymore.
[18:57] <Festor> ok, then we should put sox in Deppends?
[18:58] <pochu> we would first need to verify that solves the issue
[18:58] <ScottK> For Intrepid it sounds like recommends is appropriate (it will get installed by default).
[18:58] <cody-somerville> I'll do an upload to Intrepid right now
[18:59] <cody-somerville> Or do we want to use aplay?
[18:59] <Festor> cody-somerville, for amsn?
[18:59] <Festor> you can wait a moment?
[18:59] <Festor> I have changes for Intrepid (amsn)
[18:59] <pochu> I guess docker was moved because it isn't really *needed*
[18:59] <pochu> "    System tray for KDE3/GNOME2 docklet applications "
[18:59] <Festor> Now I little busy
[18:59] <pochu> possibly same for sox
[18:59] <pochu> is sound enabled by default in amsn?
[19:00] <Festor> no
[19:00] <pochu> so that was probably the reason
[19:00] <Festor> since feisty/gutsy
[19:00] <Festor> there is the problem
[19:00] <pochu> I guess we could put it in Recommends for Intrepid, and make it a depends for hardy and gutsy
[19:01] <persia> If it's not the default config, I'm not sure we ought make it Depends: that installs it on thousands of systems that may not need it.
[19:02] <pochu> persia: it is the default config. aplay isn't
[19:02] <pochu> it's not enabled by default, though
[19:02] <persia> pochu: Being in the default config and not enabled by default confuses me:  I'm refraining from more opinions on the subject until it's a better time of day locally.
[19:03] <highvoltage> howdy motus.
[19:04] <Festor> Now I will try sox
[19:04] <highvoltage> I lost my gpg key about 18 months ago (and its backup) and created a new one earlier this year. the problem is that it isn't signed by anyone yet
[19:04] <highvoltage> could I still submit debdiffs if I'd like to fix a bug in a package?
[19:04] <pochu> persia: sound is disabled by default, but if you enable sound, it will use play, which isn't installed, so sound won't work
[19:05] <pochu> persia: so a) we put sox in depends so it's installed, b) we switch to aplay (but that would mean alsa-tools needs to be in depends) or c) we do nothing
[19:05] <pochu> that's how I see it
[19:05] <persia> pochu: Right.  And I'm trusting others judgement on this :)
[19:05] <Festor> a)
[19:06] <cody-somerville> highvoltage, Doesn't make a difference.
[19:06] <cody-somerville> highvoltage, You aren't signing the upload :)
[19:06] <highvoltage> cody-somerville: thanks :)
[19:06] <highvoltage> aaah, ok
[19:06] <Festor> cody-somerville,
[19:06] <Festor> I can add a plugin for amsn for Intrepid?
[19:07] <cody-somerville> Festor, Maybe. You'd probably package the plugin and if you felt it should be installed by default we could add it as a recommend.
[19:08] <Festor> I say add to amsn package
[19:08] <Festor> for Intrepid
[19:08] <Festor> it this
[19:08] <Festor> http://www.amsn-project.net/plugins.php#5
[19:08] <Festor> Desktop Integration
[19:08] <Festor> I have the changes in de source code
[19:08] <Festor> for make a pacth
[19:08] <Festor> it only add a name
[19:09] <Festor> and put plugin in plugin dir
[19:09]  * persia syncs the REVU keyring
[19:09] <Festor> I think that this plugin it is usefull
[19:10] <cody-somerville> Festor, It probably is
[19:10] <Festor> Also I can make a package
[19:10] <Festor> for only this plugin
[19:10] <Festor> or at leat I think xD
[19:11] <Festor> some advice?
[19:13] <Ash-Fox> Festor, sox?
[19:13] <Festor> Ash-Fox, no
[19:13] <Festor> for the plugin
[19:13] <Festor> for sox I do not have anyone connected to the msn to test if the sox works
[19:13] <Festor> :(
[19:13] <Ash-Fox> No, you told me earlier that "Ash-Fox, for default sox is not installed"
[19:14] <Ash-Fox> But I have no idea what you're talking about.
[19:14] <Festor> ah
[19:14] <Festor> for default no
[19:14] <Festor> at least in hardy
[19:14] <Ash-Fox> What is sox to begin with?
[19:14] <Festor> https://bugs.launchpad.net/ubuntu/+source/amsn/+bug/99605
[19:15] <Ash-Fox> Okay... I don't really know how this is related to me?
[19:15] <Festor> ehh
[19:15] <Festor> I dont know... xD
[19:15] <Festor> I new here xD
[19:15] <Festor> sorry, I am new here
[19:15]  * Ash-Fox thinks you mistakened him for someone else.
[19:17] <azeem> it was a tab-completion error
[19:18] <Festor> I think that yes.... :(
[19:20] <slayton> Anybody here familiar with the Falcon Repository management software?
[19:20] <pochu> Seveas, but he's not here :)
[19:23] <stochastic> hi MOTU, I'm beginning to learn about packaging and I stumbled upon this http://mp3splt.sourceforge.net/mp3splt_page/home.php
[19:24] <stochastic> mp3split is in the hardy repos as a command line tool, but there's a mp3split-gtk available
[19:24] <stochastic> it even is available as a .deb (listed on their site as a ubuntu dapper deb) is there any reason why it's not in the hardy repos?
[19:26] <Festor> stochastic, is this package in Debian?
[19:29] <highvoltage> cody-somerville: if
[19:30] <highvoltage> oops
[19:30] <stochastic> Festor, debian's site is pretty slow, but I'm searching
[19:30] <highvoltage> if I make a change to a package, and the current version number is 3.7-2, then should the new version number be 3.7.2ubuntu0 ?
[19:31] <highvoltage> 3.7-2ubuntu-, even
[19:31] <highvoltage> ugh, 3.7-2ubuntu0
[19:31] <RainCT> highvoltage: no, 3.7-2ubuntu1
[19:32] <highvoltage> thanks RainCT. why a 1 and not a 0 though?
[19:32] <ScottK> Except in exceptional circumstances we start counting at 1.
[19:33] <highvoltage> ok
[19:33] <persia> highvoltage: If you are a diehard "counting begins at 0" person, consider 0 reserved for later use.
[19:33] <stochastic> Festor, it doesn't look like it's included in debian's repos anywhere, just on the mp3split website
[19:33] <ScottK> One reason is that if 3.7-2 is in the previous release and it needs a security update, it can be 3.7-2ubuntu0.1 without conflict.
[19:34] <pochu> stochastic: it doesn't look like it's in Ubuntu either, at least not as "mp3split"
[19:34] <pochu> ah, it's mp3splt
[19:35] <highvoltage> persia: ok :)
[19:35] <highvoltage> ScottK: aah
[19:36] <stochastic> now that I take a look at the .deb gdebi package installer tells me that beep-media-player is an unmeetable dependency, so the .deb would need some work before it can be in hardy
[19:40] <ScottK> stochastic: That's generally true of their packages.  They freely admit the don't work to Ubuntu quality standards.
[19:44] <highvoltage> cool. I have my very first debdff :)
[19:44] <highvoltage> now what do I do with it?
[19:45] <ScottK> Have it for lunch?
[19:45] <highvoltage> I guess I'll need to submit it somewhere and have it reviewed/sponsored?
[19:45] <ScottK> Yes.  What does this debdiff purport to do?
[19:46] <highvoltage> ScottK: https://bugs.launchpad.net/ubuntu/+source/pyro/+bug/178948
[19:46] <highvoltage> ScottK: it's a low hanging fruit, so I thought it would be a good first bug to fix with a debdiff
[19:46] <ScottK> highvoltage: Attach the debdiff to the bug and subscribe ubuntu-universe-sponsors
[19:46] <highvoltage> ScottK: ok, will do
[19:46] <highvoltage> thanks
[19:47] <Festor> cody-somerville, sox not work
[19:47] <Festor> I try at least three times
[19:49] <highvoltage> ScottK: ok, done it! what should I do next? just wait for one of the ubuntu-universe-sponsors to reply?
[19:50] <ScottK> Yes.
[19:50] <persia> highvoltage: Indeed.  Note that the queue is about 3 weeks long, although it's not strict FIFO, so it might be a few days.
[19:50] <ScottK> highvoltage: Is there a reason it needs to be explicitly stopped on shutdown/restart?  Can it just die with the system?
[19:51] <ScottK> highvoltage: How did you test it?
[19:52] <highvoltage> ScottK: I built the package and installed it in a chroot, and checked whether the /etc/default/pyro-nsd and /etc/init.d/pyro-nsd files existed with the correct content
[19:52] <_boto> hi joaopinto
[19:52] <highvoltage> ScottK: sorry, I meant s/nsd/esd/
[19:52] <ScottK> Right.
[19:53] <ScottK> So you don't know if the new init actually works?
[19:53] <highvoltage> ScottK: I just copied the existing pyro-nsd init and default scripts and did a search and replace so that pyro-nsd would be pyro-esd, such as the bug suggested
[19:53] <highvoltage> ScottK: hmm, you're right, I haven't thought about it like that yet
[19:54] <highvoltage> ah, it won't start up, because there's nothing that tells update-rc.d to add it.
[19:55]  * highvoltage was a bit trigger-happy here
[19:56] <ScottK> Also change +# Default-Stop:      0 1 6 to +# Default-Stop:      1 unless there is a reason it needs to be explicitly stopped.
[19:56] <highvoltage> ok
[20:01] <Festor> cody-somerville, now 2 users say that with sox amsn sound not work
[20:02] <cody-somerville> Festor, okay.
[20:03] <Festor> NeIXeR, cody-somerville -> amsn mantainer
[20:03] <joaopinto> hello _boto
[20:03] <highvoltage> ScottK: I've made the changes to the init scripts, and added the relevant update-rc.d parts in the post* scripts. should I now update the package version again, or can I just modify my changes file, since this particular package version hasn't been used yet?
[20:03] <_boto> joaopinto: did you encounter any problems with VRC?
[20:03] <persia> highvoltage: Just modify the .changes file.  Versions should only be updated on upload.
[20:03] <joaopinto> _boto, didn't had time to work on it yet :(
[20:04] <_boto> no problem ;-)
[20:04] <_boto> let me know if you need help
[20:04] <Festor> cody-somerville, So that can be done?
[20:04] <joaopinto> ok :)
[20:04] <_boto> it would be great to get it into the aptdep page ;-)
[20:04] <cody-somerville> Festor, I'm not sure what you're asking.
[20:05] <_boto> maybe once we can get it also into motu ;-)
[20:05] <Festor> How can you fix the problem?
[20:05] <Festor> I get more testers but I need time
[20:06] <NeIXeR> im the new tester
[20:06] <cody-somerville> Festor, I'll take a look at it this evening. Unfortunately I'm at work right now.
[20:07] <cody-somerville> persia, Who do I need to talk to re: mdt foo?
[20:07] <ScottK> Leave the version number the same.
[20:08] <ScottK> highvoltage: ^^
[20:08] <Festor> ok, I will try to find more testers
[20:11] <highvoltage> ScottK: thanks
[20:13] <highvoltage> ok, bug 178948 updated
[20:34] <Festor> cody-somerville, news
[20:34] <cody-somerville> Festor, feed
[20:34] <Festor> in Ubuntu 7.04 when user install sox, amsn sound work
[20:34] <Festor> but in Ubuntu 7.10 and 8.04 no
[20:35] <Festor> in Ubuntu 7.10 and 8.04 only works with aplay
[20:35] <cody-somerville> Okay.
[20:35] <cody-somerville> Good work
[20:36] <Festor> this means that for 7.04 only need add a dependecy
[20:36] <Festor> but for 7.10 and for 8.04...
[20:36] <Festor> use patch?
[20:37] <Festor> I will try find a user of 7.10 with amsn
[20:37] <Festor> for test again
[20:37] <Festor> I have 2 user (one me) of 8.04
[20:37] <Festor> and 1 of 7.04
[20:38] <null_vector> for bug 91237, the patch needs to be edited.  Just edit the patch and list that in the changelog
[20:38] <null_vector> ?
[20:40] <Festor> cody-somerville, sox of 7.04 is not same of sox of 8.04
[20:41] <Festor> The program has fewer packages
[20:48] <Festor> ScottK, are you here?
[20:48] <ScottK> Barely.
[20:49] <Festor> I have new about amule package
[20:49] <Festor> 	
[20:49] <Festor> In the end, will require patch 2.2.1 with the patch of 2.2.2
[20:50] <Festor> because, 2.2.2 require libupnp3
[20:50] <Festor> and hardy -> libupnp2
[20:50] <Festor> so we wait for patch of 2.2.2?
[20:50] <Festor> I could make a package?
[20:51] <Festor> when 2.2.2 release
[20:51] <Festor> package for me = .diff.gz
[20:51] <Festor> cody-somerville, now I have test in Ubuntu 7.04, 7.10 and 8.04
[20:52] <Festor> sox only works in 7.04
[20:53] <Festor> wait a moment
[20:55] <ScottK> Festor: Let's get 2.2.2 into Intrepid first.  Then we'll talk Hardy.
[20:56] <Festor> ok
[20:57] <Festor> but 2.2.2 maybe will have a new feature in amule deb package
[20:57] <Festor> I find a amule.schemas for add ed2k links of firefox to amule
[20:57] <Festor> and works!
[20:57] <Festor> I want add this schemas for Intrepid
[20:58] <ScottK> Festor: Get the basic one uploaded and then add that later.
[20:59] <Festor> ok
[21:04] <Festor> cody-somerville, more news and the last
[21:04] <Festor> the problem is only in Ubuntu 8.04
[21:04] <Festor> and only gets sound with aplay
[21:05] <Festor> I try all that I know
[21:05] <Festor> And I get help with some testers
[21:05]  * slytherin dances with joy. batik 1.7 built. :-D
[21:09] <geser> \o/
[21:09] <slytherin> geser: I want a party from you and persia. :-)
[21:53] <askand> Hello, is the procedure of getting something in to universe almost the same as getting something in main?
[21:55] <ScottK> askand: The procedure for getting something into Main starts with getting it into Universe.
[21:56] <askand> That I know :) I just want to know how the procedure for getting something in to universe goes
[21:58] <null_vector> Any special procedure to follow when forwarding patches upstream?
[21:58] <geser> askand: completely new package or already packaged in Debian?
[21:59] <ScottK> null_vector: Where is upstream?
[21:59] <null_vector> findutils on savannah
[22:00] <askand> ﻿geser: there wasnt anything particular at the moment really, just interested :) got links or something
[22:02] <jpds> !packguide | askand
[22:02] <geser> askand: there are two ways to get a package into universe: a) get it packaged in Debian and sync over and b) through REVU
[22:03] <askand> thanks
[22:08] <ScottK> null_vector: My primary advice would be to NOT tout the advantages of using a proprietary bug tracker like Launchpad.
[22:08] <ScottK> null_vector: Do you know for sure it's an upstream issue not related to Ubuntu or Debian packaging?
[22:10] <null_vector> yeah, bug #202431
[22:13] <ScottK> Is the man page in the upstream part of the package or in the debian dir?
[22:14] <DktrKranz> does someone know what happened to {ftp-master,incoming}.debian.org ?
[22:15] <tooba2> it's not the first time it's down, in the last days
[22:15] <Laney> DktrKranz: I'm guessing something is down, p.d.o is dead too
[22:15] <DktrKranz> gah
[22:15] <DktrKranz> I hope nothing critical, last time it was horrible
[22:16] <Laney> What was it before?
[22:16] <DktrKranz> IIRC, some disk crashed and it went down for a week
[22:16] <ajmitch> not all debian hosts are down, at least
[22:19] <null_vector> it's upstream and I've got a patch ready against HEAD
[22:20] <tooba2> packages.debian.org up again
[22:20] <tooba2> but slow
[22:26] <ScottK> vorian: How's that?
[22:41] <Laney> If anyone has time, I've a package (btnx) on REVU which could do with a review :)
[22:44] <ScottK> Laney: Generally if you give a link your odds go up.
[22:44] <Laney> ScottK: Right, went for terseness. http://revu.tauware.de/details.py?package=btnx
[22:47] <tooba2> Laney: in the description there is a typo: "it's buttons" should be "its buttons"
[22:49] <Laney> I knew I should have proof read that closer ;)
[22:49] <Laney> (copied from upstream)
[22:49] <Laney> Actually, that bit should probably be rewritten a bit anyway
[22:55] <norsetto> laney: If the license is GPL-2 change the pointer in debian/copyright to /usr/share/common-licenses/GPL-2
[22:55] <Laney> norsetto: Check
[22:56] <tooba2> Laney: do you already know about "script-in-etc-init.d-not-registered-via-update-rc.d" lintian error?
[22:56] <Laney> tooba2: I did not see that
[22:57] <tooba2> laney:http://paste.ubuntu.com/24817/
[22:58] <Laney> tooba2: Ah, I didn't run lintian on the deb, good catch!
[22:58] <norsetto> laney: also, change Section: universe/utils to utils only
[22:58] <norsetto> laney: do we have btnx-config?
[22:59] <Laney> norsetto: That's awaiting REVU too ;)
[23:00] <tooba2> open question to expert MOTUs: if they depend each one on the other, does it make sense to split them?
[23:01] <Laney> They're two separate codebases upstream
[23:01] <Laney> (and btnx doesn't technically depend on -config, I've reworded that part)
[23:01] <tooba2> I see
[23:01] <norsetto> tooba2: dependency loops shall be avoid unless necessary (which is the case in only few cases)
[23:02] <Laney> norsetto: Is it valid to put -config as a Suggests: though?
[23:02] <tooba2> norsetto: thanks. Good night, everybody (whenever it will be for you)
[23:02] <norsetto> Laney: no idea what -config does, will it enhance the btnx package?
[23:03] <Laney> norsetto: It lets you configure it
[23:03] <norsetto> Laney: what I mean is, will btnx run without it? Will it be better with it?
[23:03] <Laney> So then you'd have -config depends: btnx and btnx suggests: -config
[23:04] <Laney> Yes, it'll be better with it. I don't know if you can configure btnx without -config, actually.
[23:04] <norsetto> Laney: well, then btnx-config shall be a dep of btnx
[23:04] <Laney> norsetto: But that would be a dependency loop
[23:05] <norsetto> Laney: no, because btnx-config won't depend on btnx
[23:06] <norsetto> Laney: from what you tell me, you can install btnx-config (even though it will be useless), while you can install btnx without btnx-config
[23:06] <norsetto> Laney: "while you can't install btnx without btnx-config" even
[23:06] <Laney> norsetto: You can install both without the other, but I don't know if you'd ever want to
[23:07] <Laney> I'm thinking btnx-config depends on btnx and btnx recommends/suggests -config, so as not to create a loop if this is legal.
[23:08] <Laney> There could be a time in the future when we get btnx-config-qt, for example
[23:08] <Laney> or a console version, whatever.
[23:08] <norsetto> Laney: it all depends (pun intended) if btnx can be used without the gui
[23:09] <Laney> norsetto: It can be used but not configured AIUI
[23:10] <norsetto> Laney: can it be configured manually!?
[23:11]  * Laney checks
[23:13] <norsetto> Laney: having this binary in /usr/sbin is against the FHS in my opinion
[23:13] <Laney> norsetto: Right. You can configure it by editing a file in /etc/btnx, although it's not very friendly. But possible.
[23:15] <norsetto> Laney: ok, I would make btnx-config a recommend of btnx and no deps in btnx-config on btnx
[23:15] <Laney> norsetto: Are you sure? -config is useless without btnx
[23:15] <Laney> and re: the FHS, btnx runs as a daemon. Does that affect whether it lives in /usr/sbin?
[23:16] <norsetto> Laney: it doesn't matter if its a daemon or not, the FHS is pretty clear on what can go there: http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
[23:18] <Laney> norsetto: I will put it in /usr/bin then
[23:18] <norsetto> Laney: the alternative is to have btnx stand alone and btnx-config have a dep on btnx
[23:18] <Laney> norsetto: That's what I have now. I think that approach is more correct IMO - just didn't know whether btnx could (or even should) recommend or suggest btnx-config.
[23:19] <norsetto> Laney: mind you that the alternative its pretty standrd for programs which have stand-alone guis
[23:20] <Laney> I guess I'm thinking of a situation where you just install btnx and copy the config file around
[23:21] <norsetto> Laney: in the README it says "
[23:21] <norsetto> You must install
[23:21] <norsetto> and run btnx-config before btnx will work
[23:21] <Laney> norsetto: Yeah, upstream says that. But it does work without it
[23:22] <norsetto> Laney: do you need (>= 0.21) for pkg-config?
[23:25] <Laney> norsetto: I got that from upstream
[23:25] <Laney> Which is another way of saying that I don't know ;)
[23:28] <norsetto> Laney: where is that? In his webpage? 'cause there is no version check in his configure
[23:29] <Laney> norsetto: He has a PPA version which has that b-d
[23:30] <norsetto> Laney: looks fishy to me, I would just use pkg-config, not that we really want to backport this to dapper but, if its not needed, lets not use it
[23:30] <Laney> OK, I guess it doesn't matter
[23:31]  * Laney also removes debhelper b-d as that is pulled in by cdbs
[23:33] <norsetto> Laney: add copyright in debian/copyright, note that there is something funky in revoco.c
[23:34] <Laney> Ooh, good catch
[23:34] <norsetto> Laney: file revoco.c has no copyrights (it was written by an animal) :-)
[23:35] <norsetto> Laney: that is from btnx.c
[23:35] <tacone> animals ?
[23:35]  * Laney has no idea what that means
[23:36] <Laney> norsetto: http://nion.modprobe.de/blog/archives/535-Fun-with-copyright.html
[23:37]  * Laney gets even more confused, very weird
[23:37] <norsetto> Laney: and the init file is just s**t, you should rewrite it from scratch
[23:39] <norsetto> Laney: forget that. I was looking at the wrong file (phew)
[23:39] <Laney> norsetto: The init file thing?
[23:40] <norsetto> Laney: yes, why is cdbs not adding adequate prerm, postinst scripts? God bless cdbs
[23:41] <Laney> Hmm, I guess this is why the update-rc.d warning is happening
[23:41]  * Laney digs
[23:42] <norsetto> Laney: anyhow, give a through check to the init file, it looks like if it fails will make the package uninstallable and unremovable
[23:46] <Laney> Oh whoops, looks like I've had btnx-config installed all along, and it *is* a dep after all.
[23:54] <norsetto> Laney: then we have no choice, btnx depends on btnx-config and btnx-config doesn't relate to btnx
[23:55] <Laney> norsetto: Yes, I've done that
[23:55] <Laney> And I agree with you about the init file, needs a bit of work
[23:55] <norsetto> gotta go now, see you all again