[00:09] <jono> what is the best wiki page to read that outlines the quality checks that are made for new packages in Ubuntu?
[00:11] <tumbleweed> Laney: Haskell page on the wiki says I should ask you: http://launchpadlibrarian.net/50767019/buildlog_ubuntu-maverick-armel.haskell-testpack_2.0.0-3_FAILEDTOBUILD.txt.gz
[00:13] <Laney> tumbleweed: you need to rebuild those dependencies
[00:13] <tumbleweed> Laney: I was guessing as much
[00:13] <Laney> you might find http://orangesquash.org.uk/~laney/haskell-installability/armel.png useful
[00:14] <Laney> but if you're just fixing stuff off the FTBFS list then I'd ignore Haskell things for now
[00:14] <tumbleweed> Laney: no that was an upload of mine
[00:15] <tumbleweed> I can have a prod at the dependancies
[00:15] <Laney> cool
[00:15] <Laney> i should chase down those haskell merges
[00:16] <Laney> http://pastebin.ca/1888897
[00:18] <jpds> Laney: Dude, that thing killed X.
[00:19] <Laney> You need a better X!
[00:19] <jpds> Here's some big .png's from me: http://people.canonical.com/~jpds/mirrors/
[00:20] <lifeless> morning jpds
[00:20] <jpds> Evening lifeless.
[00:20] <lifeless> jono: I'm not sure there is one.
[00:20] <jono> lifeless, thats what I thought
[00:21] <lifeless> jono: there are two basic checks: 'package is good' - which is the union of all quality guidelines.
[00:21] <lifeless> so a page just listing it would be a) huge and b) out of date on day 2.
[00:21] <Laney> jono: will try to reply to your mail tomorrow
[00:22] <lifeless> the second check is 'package copyright and license are documented well enough [and compatible with the suite they are going to be put into'
[00:22] <lifeless> which is actually conceptually redundant with the first check (and package merges from $source [e.g.] upstream *really should* check this hasn't changed, its a bit of a hole at the moment.
[00:22] <lifeless> jono: ^
[00:25] <jono> Laney, awesome, I am just writing another change and merging in mdz's comments
[04:50] <EzraR> anyone want to revu a package :) should be an easy review allready has one akk
[05:59] <NorthernLights> Hi there
[06:51] <dholbach> good morning
[06:58] <iulian> Morning Daniel.
[06:59] <dholbach> hey iulian
[07:26] <didrocks> hyperair: Laney: FYI, I will make some packaging changes to Banshee (enabling some plugin by default and make some patch), the idea is to experiment there and once stabilized (I hope in one week approximately), I will sum up changes that should be upstreamed and those which make sense to Debian as well. Does it sound ok?
[07:27] <hyperair> where is there?
[07:27] <didrocks> hyperair: for now, my changes is just in a bzr branch, one sec
[07:27]  * hyperair groans at the mention of bzr
[07:28] <didrocks> hyperair: it's just easier in my system and make sense.
[07:28] <didrocks> hyperair: https://code.edge.launchpad.net/~didrocks/banshee/une-modif
[07:28] <didrocks> hyperair: it's really small tweaking for now, mostly make it fit in non meego environment
[07:38] <hyperair> didrocks: those look like changes that should be upstreamed immediately, to be honest.
[07:39] <didrocks> hyperair: well, I'm not quite sure it's the definitive answer, that's why I want to test them before next banshee release, (I'm waiting for the last change I discussed in Banshee ML first). But I can post on both
[07:39] <hyperair> post on both what?
[07:42] <didrocks> hyperair: upload to ubuntu and propose them to upstream
[07:44] <hyperair> i'd prefer you propose them upstream first, then upload to ubuntu.
[07:45] <didrocks> hyperair: well, that's the same in a question of 10 minutes delay, but if this matters to you
[07:45] <hyperair> i'm rather apprehensive about having Ubuntu's Banshee package fork from Debian at all, and to a slightly lesser extent, about having Debian's package fork from upstream at all.
[07:46] <hyperair> in fact, i'd propose you do all this testing in a PPA, rather than putting it into maverick directly.
[07:46] <didrocks> hyperair: well, the only change I think that you want in Debian is enabling the import from ~/Music and ~/Video by default
[07:46] <didrocks> hyperair: well, maverick is unstable
[07:47] <didrocks> hyperair: I don't see why those changes who works shouldn't go to maverick
[07:47] <didrocks> but ok, I'll post my patches upstream and upload the changes to ubuntu
[07:48] <hyperair> just a question.. exactly what changes are you planning to include?
[07:48] <hyperair> importing of ~/Music and ~/Video by default is something i wouldn't condone.
[07:48] <hyperair> a prompt would be good
[07:48] <hyperair> i think it was mentioned on the mailing list
[07:48] <hyperair> "Do you want to import .... "
[07:48] <didrocks> hyperair: yeah, and I gave some answer to them. Prompts are ugly on first launch
[07:49] <didrocks> hyperair: for the changes, did you see my branch ^
[07:49] <hyperair> but importing automatically is getting ahead of yourself.
[07:49] <hyperair> i saw 5 commits, but i'm thinking you might have other changes in mind?
[07:49] <hyperair> i'm asking about all the *planned* changes, not just the ones you've already done so far.
[07:50] <didrocks> hyperair: just the notification think we discussed on IRC. It's really small things, as said
[07:50] <didrocks> and enabling import by default
[07:50] <hyperair> notification?
[07:50] <hyperair> what notification?
[07:51] <didrocks> hyperair: the "your list of music is empty, if you want to fill it up, please use the import or drop in …"
[07:51] <hyperair> er, isn't that kind of redundant with importing from ~/Music and ~/Videos by default?
[07:52] <hyperair> or do you mean it as a mutually exclusive thing?
[07:52] <didrocks> hyperair: not really, because if you activate importing from ~/Music and ~/Videos by default and you don't have music there
[07:52] <didrocks> you should be told where to put your music
[07:53] <hyperair> i get the feeling i'd be really annoyed if i tried banshee for the first time and it immediately imported my ~/Music and ~/Videos immediately.
[07:54] <hyperair> i'd be happier if it popped up the import dialog on first run though
[07:54] <didrocks> hyperair: really? prompting has been defeated. Do you remember amarok in KDE3?
[07:55] <hyperair> i remember using the old amarok, ages ago.
[07:55] <didrocks> it went to an extense "which DB do you want to use"
[07:55] <hyperair> that was ridiculous.
[07:55] <didrocks> right, I think for most of people telling where your music should be imported is the same
[07:55] <hyperair> but amarok lost many amarok1.* users
[07:56] <hyperair> i've seen many amarok 1.* users jumping over to banshee
[07:56] <hyperair> because they hate amarok2.
[07:56] <hyperair> doesn't that say something to you?
[07:56] <didrocks> well, I switched to rhythmbox :)
[07:56] <didrocks> at the time
[07:56] <RAOF> But amarok2 drastically changed the UI, and was broken for ages, wasn't it?
[07:57] <hyperair> and does rhythmbox automatically import ~/Music and ~/Videos without letting the user know?
[07:57] <hyperair> i don't think so.
[07:57] <hyperair> at least, i don't remember rhythmbox doing something like that, or i'd have held a strong grudge against it
[07:57] <didrocks> hyperair: we are discussing doing that as well
[07:58] <RAOF> hyperair: Why?  As long as it defaults to not touching the files, why would you _not_ want an audio file in ~/Music to be in your Banshee DB?
[07:58] <hyperair> RAOF: because importing is a CPU and I/O intensive process that is likely to slow down the computer and i don't want it to be doing something like that without my knowledge.
[07:59] <didrocks> I still think this is the goal of Ubuntu: making things easy to the user, and have something ready out of the box
[07:59] <RAOF> It wouldn't be without your knowledge, though - it'd say “importing files”
[08:00] <hyperair> didrocks: i'd rather you talk to upstream *properly* and come to a consensus about this before pulling something like this.
[08:00] <RAOF> While you can _technically_ use Banshee without having a local library, it's fundamentally a media library program and deliberately not having media listed in the library seems strange.
[08:00] <hyperair> RAOF: some people (like me) have focus prevention on which makes new windows appear behind the currently focused windows.
[08:01] <didrocks> hyperair: why? does GNOME upstream decide about distro app by default, for instance?
[08:01] <hyperair> RAOF: this means banshee will appear behind what i'm currently working on, and then will cause my computer to slow down and have weird hangs here and there, and i will be wondering wtf is going on, until i start conky and seeing banshee consume 100% of my CPU and 100% of my I/O.
[08:02] <hyperair> or top, or gnome system monitor, for that matter.
[08:02] <hyperair> didrocks: that's a different matter, imo
[08:03] <didrocks> I disagree, that's not different, we change also a lot of gconf settings and debian does in /usr/share/gconf/defaults/
[08:03] <hyperair> didrocks: and banshee upstream has already taken statistics, and found that most of the Banshee users are Ubuntu users. we're talking about moer than 50% here, somewhere around 70%.
[08:03] <hyperair> didrocks: this means they will be willing to compromise, and listen to anything Ubuntu has to say
[08:04] <hyperair> which also means we shouldn't push them away and introduce changes like this.
[08:04] <didrocks> hyperair: I can engage the discussion on the import by default settings, but for me, it's still a setting
[08:04] <hyperair> it will cause unnecessary drift between Ubuntu and upstream Banshee.
[08:08] <hyperair> then please do engage in the discussion. if upstream really doesn't agree, and the desktop team decides that it's better for all media players to automatically import on first run, then let's consider a downstream patch.
[08:10] <didrocks> hyperair: I'm preparing an email on banshee ML right now
[08:10] <hyperair> okay
[08:10] <superm1> hyperair, importing doesn't have to be CPU intensive or IO intensive though
[08:11] <hyperair> superm1: i think it's a bug filed on banshee somewhere.
[08:11] <RAOF> Well, it's probably going to be a bit I/O intensive.
[08:12] <hyperair> superm1: but for huge ~/Music (20G+) folders, which i'm sure many have, Banshee will need to scan for all media files, read their tags, optionally perform Mirage's scanning and BPM detection....
[08:12] <hyperair> it's going to be both CPU and I/O intensive.
[08:12] <superm1> that's not to say that can't be improved though with lower priority threads
[08:13] <RAOF> But it's not going to perform mirage scanning or bpm detection because they've just started up, and neither of those are enabled by default.
[08:13] <hyperair> our dear Completely Fair Scheduler has a habit of making X's cursor motion lag during heavy CPU of even processes/threads with high nice values.
[08:14] <hyperair> RAOF: doesn't it perform those when importing music?
[08:14] <RAOF> hyperair: Only when they're enabled.
[08:14] <RAOF> We're talking about import on first launch - there's no way the user could have enabled them yet.
[08:15] <hyperair> RAOF: ah, they're not enabled by default then?
[08:15]  * hyperair has forgotten
[08:15] <RAOF> Not enabled by default, no :)
[08:15] <hyperair> i see.
[08:15] <hyperair> well then that just leaves the heavy I/O of staring at the tags and recording them in the sqlite DB.
[08:15] <RAOF> Yeah.
[08:16] <RAOF> I'm not convinced that anyone's going to start up banshee for the /first time/ and leave it running in the background.
[08:17]  * hyperair shrugs.
[08:17] <hyperair> maybe not, but i'd still be happier to see something like...
[08:18] <RAOF> I mean, sure - we should ensure that the IO problem is minimised.
[08:18]  * RAOF heads livingroomward for bonus gas fire.
[08:18] <superm1> RAOF, what was that i saw murmured about hotplugging vga and intel the other day?
[08:19] <hyperair> how about when banshee's collection is empty, the treeview widget gets disabled and on top of it, a message that says "Your collection is empty. Do you want to import media?"
[08:19] <hyperair> something like how DAAP shares which can't be connected to get a message
[08:19] <didrocks> hyperair: still not sure, not ready "out of the box"
[08:20] <RAOF> Yeah, I think that would be a good idea.  It would be nicer if Banshee saw “hey, you've got audio files in ~/Music - I'm guessing that's your music”, though.
[08:20] <hyperair> RAOF: yeah, that's exactly what i'm thinking about.
[08:20] <didrocks> oh, btw, I just tried meego during we were discussing, there are enabling the plugin… I was thinking it was upstream banshee who made the tweaks, isn't it?
[08:21] <hyperair> didrocks: next you'll be telling me that mail clients shouldn't require account setup, but should automatically read the user's mind for usernames and passwords and automatically fetch mail.
[08:21] <RAOF> superm1: It works, and with the new xserver TheMuso sponsored for me it won't freeze compiz, either!
[08:21] <didrocks> hyperair: you are not being positive there.
[08:21] <hyperair> didrocks: i'm putting things in perspective.
[08:21] <superm1> RAOF, oooh purdy.  is it done in a nice way that other drivers will be able to add the functionality too?
[08:21] <RAOF> hyperair: If there was a ~/this-is-my-email-setup I totally _would_ expect email programs to read that on startup.
[08:22] <didrocks> there is no way to guess your email account
[08:22] <RAOF> superm1: nouveau already supports it, and I'm pretty sure radeon does, too.
[08:22] <didrocks> but there are for your music and video
[08:22] <superm1> RAOF, awesome!
[08:22] <hyperair> didrocks: okay, another example. you know how chromium prompts for importing of data from firefox/any other browser on your system?
[08:22] <hyperair> didrocks: in your case, it would *automatically* do that, without prompting.
[08:23] <superm1> on some hardware i've seen fglrx blob do something like that too, but it was probably cheating since it gets to leave a daemon running
[08:23] <didrocks> hyperair: this is because your are transitionning from one software to another
[08:23] <didrocks> hyperair: if I use rhythmbox
[08:23] <didrocks> and banshee propose me to import the rhythmbox collection
[08:23] <didrocks> that would make sense
[08:24] <RAOF> superm1: the kernel modules now trigger uevents on input hotplug, and the DDX is able to catch them.
[08:25] <hyperair> didrocks: it just seems to me like more consistent behaviour to follow the same first-time-running procedure for all use cases, whether the user has previously used rhythmbox, amarok, itunes, or not.
[08:25] <didrocks> hyperair: I clearly disagree on that point and it seems we won't reach an agreement there :/
[08:25] <hyperair> didrocks: so that when banshee first starts up, it brings up the first time running dialogue, which asks if the user wants to: i) import music from some other player, ii) import music from ~/Music
[08:26] <didrocks> do you imagine if every software would do that?
[08:26] <didrocks> a prompt at startup
[08:26] <didrocks> or worse, the "hint of the day" :-)
[08:26] <hyperair> a hint of the day is useless, imo, and can't really compare to this.
[08:27] <RAOF> hyperair: Apart from the IO issue, is there any other reason why you wouldn't want to have ~/Music in your banshee db?
[08:28] <hyperair> didrocks: okay, supposing that i did transition from Rhythmbox to Banshee, but my ~/.rhythmbox or whatever it is, isn't in a standard location, say an old /home directory which isn't /home any more.  Banshee starts up for the first time and immediately begins importing everything. what i'll need to do is cancel the importing, and then use the import media dialogue to specify that other location.
[08:29] <didrocks> hyperair: seems a more advanced use case to me
[08:29] <didrocks> hyperair: we are trying to adress the daily computer user, non geek one
[08:30] <didrocks> this one will use the default folder by default, that's why they are there
[08:30] <hyperair> didrocks: i understand that, but while we are trying to address the daily computer user, we end up creating loops for the geek ones to follow.
[08:30] <didrocks> hyperair: is it so much overhead?
[08:31] <didrocks> otherwise, we can propose installing GNOME or openbox if we want to go down the path :)
[08:31] <RAOF> But we're not talking about automatically importing ~/.rhythmbox; we're talking about ~/Music.
[08:32] <hyperair> RAOF: automatically importing ~/Music instead of ~/.rhythmbox makes rhythmbox->banshee users, which there will inevitably be, if Ubuntu switches to Banshee as default, lose all their ratings, play and skip counts.
[08:32] <hyperair> RAOF: that won't be pretty.
[08:33] <didrocks> hyperair: for people upgrading, they still have rhythmbox, we don't remove apps by default
[08:33] <didrocks> hyperair: it's for UNE users btw, not desktop ones
[08:34] <RAOF> hyperair: What happens if users then import their Rhythmbox library?
[08:35] <RAOF> IE: is there any reason why they couldn't later on import their Rhythmbox library, and have their ratings, play, and skip counts merged into the Banshee db?
[08:36] <directhex> FWIW rhythmbox imports my stuff by default. but i think it does ~
[08:37] <hyperair> RAOF: i dunno, i've never attempted.
[09:26] <didrocks> hyperair: did you try the banshee indicator in your previous upload? it doesn't work
[09:33] <hyperair> didrocks: eh? the one i just did hours ago?
[09:34] <didrocks> hyperair: right, I was hoping your rebuild with new -cli fixes it as you uploaded it
[09:34] <hyperair> no i didn't test it on maverick
[09:35] <didrocks> oh ok…
[09:35] <hyperair> didrocks: could you file a bug?
[09:35] <didrocks> hyperair: sure
[09:36] <hyperair> or maybe reopen the bug that was closed by that upload..
[09:36] <hyperair> no on second thoughts a new bug would be better
[09:36] <hyperair> didrocks: could i see the output of "banshee --debug"?
[09:36] <didrocks> hyperair: ok, will do :) btw, why do you enable lirc by default only on ubuntu
[09:36] <didrocks> sure, one sec
[09:36] <hyperair> didrocks: because the build-deps aren't satisfied on debian.
[09:37] <hyperair> didrocks: i remember poking someone about lirc on debian,  but he seemed to run into problem after problem trying to get lirc updated on debian. something about the debian team not acting, or something.
[09:38] <didrocks> hyperair: http://paste.ubuntu.com/453811/
[09:38] <didrocks> hyperair: ok, make sense
[09:40] <hyperair> didrocks: is that all that's mentioned? or is there any more?
[09:40] <didrocks> hyperair: no, even with --debug
[09:41] <hyperair> hmm
[09:41] <didrocks> (when I activate the indicator extension)
[09:41] <hyperair> well file a bug and subscribe qense to it then =)
[09:43] <didrocks> ok :)
[10:32] <huats> morning
[10:33] <shadeslayer_> huats: hey
[10:33] <eagles0513875> shadeslayer_: poke
[13:16] <dholbach_> can I persuade somebody to give a session at Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[13:34] <Rhonda> I got a mail that wesnoth-1.8 got accepted into karmic-backports, but rmadison doesn't show it yet, neither packages.ubuntu.com?
[13:36] <wgrant> Rhonda: It's in NEW.
[13:36] <wgrant> So you probably didn't get an email of acceptance.
[13:39] <Rhonda> I got a Fix Released launchpad notice.
[13:40] <Rhonda> I thought that would mean release. :)
[15:40] <Philip5> is it possible somehow to set at ie [i386] rule in a packagename.install file to controll if a file should be installed on [i386] but might not exist on [amd64]?
[15:40] <Philip5> or do i have to installed the file from debian/rules?
[15:41] <Philip5> anyone done this with .install files?
[15:44] <ScottK> Rhonda: I just pushed it through source New.  It'll hit binary New again after it's built though.
[15:46] <ScottK> Philip5: Something like this is done in kdebase-workspace for linux/non-linux architectures (Debian has non-linux architectures), so you might look at it for inspiration.
[15:47] <Philip5> ScottK: i'll have a look... i thought it would be nicer to do it that way than moving files in rules
[15:48] <Rhonda> ScottK: Ah, alright. :)
[15:48] <ScottK> Philip5: It uses arch specific install files and you can see how they use them in debian/rules
[16:31] <EricBa> Hello, is there a motu who has some time to review my package? It's already reviewed by one motu. My programm is a wallpaper changer for gnome. - http://revu.ubuntuwire.com/p/cortina It was already advocated by one reviewer.. so this won't take much time to review.
[16:34] <Rhonda> Yet another wallpaper changer for gnome? :)
[16:37] <shadeslayer_> tumbleweed: poke
[16:38] <tumbleweed> shadeslayer_: not a good time, about to go to pub quiz
[16:38] <shadeslayer_> sure
[16:38] <shadeslayer_> tumbleweed: any idea when you will be back?
[16:38] <tumbleweed> shadeslayer_: ~11pm SAST
[16:38] <shadeslayer_> ok
[16:42] <EricBa> Rhonda: exactly this one ;) I dont wont to manage my program on sourceforge, softpedia,.. etc. It's hard to upload it to every side
[16:43] <shadeslayer_> ok,since im using source format v3 i dont need a watch file right?
[16:43] <Rhonda> What has watch file to do with source format v3?
[16:43] <shadeslayer_> Rhonda: well i was advised not to use get-orig-source in rules,so im asking if i need a watch file
[16:44] <Rhonda> watch file is about getting notifications about new upstream versions. I have no idea why this should be obsoleted with source format v3
[16:44] <shadeslayer_> ok
[16:44] <Rhonda> not use get-orig-source? Why not?
 shadeslayer_: have you thought about using v3 source format? that way you could use the upstream tar.bz2 as is (v3 gives you "You don't have to repack the upstream tarball to strip the debian directory." for free)
[16:45] <tumbleweed> shadeslayer_: sounds sensible ^
[16:46] <shadeslayer> tumbleweed: ok.. so dont use get-orig-source,but i do need to add watch file
[16:46] <tumbleweed> shadeslayer: you always should have a watch file
[16:46] <tumbleweed> (unless upstream doesn't have tarballs of any form)
[16:47] <shadeslayer> ok
[16:50] <Rhonda> shadeslayer: But from what I understand get-orig-source isn't only about repacking the upstream source but fetching too.
[16:52] <Rhonda> Especially repacking usually doesn't produce the same hash, or do I completely misunderstand the target?
[16:52] <Rhonda> repacking again, that is
[17:00] <shadeslayer> Rhonda: do we prefer a patch system or can the patches be inline?
[17:02] <Rhonda> Who is we - and I don't get your question.
[17:02] <shadeslayer> Rhonda: we == Ubuntu packagers?
[17:03] <Rhonda> patch system is always preferred to have the patches seperated
[17:04] <shadeslayer> hmm ok
[17:14] <shadeslayer> Rhonda: hmm : dpkg-source: error: LC_ALL="C" LANG="C" patch -s -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/01_kubuntu_translate_patch.patch/ gave error exit status 1
[17:17] <shadeslayer> more info http://pastebin.com/thnErWSu
[17:23] <shadeslayer> btw i dont need : opts=dversionmangle=s/\+ds// \ since im not repacking source now,right?
[17:23] <shadeslayer> im debian/watch
[17:24] <shadeslayer> *in
[17:39]  * shadeslayer wonders who will answer
[18:05] <tumbleweed> shadeslayer: correct (my quiz was cancelled)
[18:05] <shadeslayer> tumbleweed: idk if i should be happy or sad :P
[18:06] <shadeslayer> tumbleweed: ok,i have a patching error
[18:07] <shadeslayer> tumbleweed: http://shadeslayer.pastebin.com/qLULztwE
[18:07] <shadeslayer> if i use patch -p0 <mypatch.patch , it works
[18:08] <shadeslayer> hmm.. hold on .. i think i have to add the patch system to rules
[18:09] <tumbleweed> shadeslayer: quilt patches should be p1
[18:12] <shadeslayer> tumbleweed: anyways.. any idea what i should add in debian/rules to enable patches?
[18:12] <tumbleweed> with source format 3, nothing. it happens automatically on dpkg-source -x
[18:13] <shadeslayer> any idea on the error then?
[18:17] <tumbleweed> shadeslayer: 19:09 < tumbleweed> shadeslayer: quilt patches should be p1
[18:18] <shadeslayer> tumbleweed: no so what do i do to correct it :P
[18:18] <tumbleweed> shadeslayer: do you know that the -p flag does?
[18:24] <shadeslayer> tumbleweed: no
[18:25] <tumbleweed> it's the number of directories to strip off the front of every path in the patch file
[18:25] <shadeslayer> ah ok
[18:25] <shadeslayer> so i guess my patch is bad?
[18:26] <shadeslayer> tumbleweed: http://pastebin.com/upWBzryf
[18:27] <tumbleweed> that's a simple patch, so you can just manually edit it. Add something random to the beginning of each path. i.e. a/ and b/
[18:28] <shadeslayer> tumbleweed: w00t
[18:28] <shadeslayer> building in pbuilder and will upload
[18:30] <tumbleweed> shadeslayer: while you are waiting, look at this: http://dep.debian.net/deps/dep3/
[18:31] <shadeslayer> ok
[18:32] <shadeslayer> tumbleweed: thanks for all the help ;)
[18:37] <shadeslayer> tumbleweed: i fixed this issue earlier,but dont remember now : http://shadeslayer.pastebin.com/7gVvaLVK
[18:37] <shadeslayer> how to fix it
[18:41] <tumbleweed> shadeslayer: so, where does the contents of the .changes file come from?
[18:42] <shadeslayer> tumbleweed: uh.. from debuild?
[18:43] <tumbleweed> no, I mean where does it get the contents that it puts in there from?
[18:44] <geser> Changed-By is the from the last changelog entry
[18:44] <shadeslayer> tumbleweed: hmm.. debian/changelog
[18:44] <tumbleweed> shadeslayer: so, look at that error, and the changelog, and see if you can see why you are getting it
[18:45] <shadeslayer> hmm... cant see why its giving that
[18:46] <tumbleweed> how is your change signed off in the changelog? paste that line
[18:46] <geser> can you paste the line from your changelog entry beginning with " --"?
[18:49] <shadeslayer> geser:  -- Rohan Garg <me@gmail.com>  Tue, 22 Jun 2010 20:56:42 +0530
[18:50] <geser> hmm
[18:51] <shadeslayer> geser: ill remove the changelog and create a new one
[18:58] <shadeslayer> geser: is it necessary to do dep3 ?
[19:00] <geser> it's no requirement, but it has some advantages and some people like to see the dep3 headers on patches
[19:01]  * shadeslayer doesnt want to do more additions/changes  :P
[19:02] <shadeslayer> geser: and its still complaining about the chages
[19:02] <shadeslayer> *changes
[19:02] <geser> hmm
[19:08] <shadeslayer> geser: im uploading it,i think lintian has gone mad :P
[19:08] <shadeslayer> apart from that there are other lintian errors that can be ignored.. binary without manpage stuff....
[19:15] <shadeslayer> geser: http://revu.ubuntuwire.com/details.py?upid=8334
[19:15] <shadeslayer> tumbleweed: ^^
[19:19] <RainCT> didrocks: Hey
[19:20] <RainCT> didrocks: I've created https://code.edge.launchpad.net/~zeitgeist-packagers
[19:21] <sebner> RainCT: tell him to switch to dh7 or I'm gonna cry :P
[19:21] <RainCT> sebner: lol. It is hd7 in Debian :)
[19:21] <RainCT> *dh7
[19:21] <sebner> didrocks: don't be such a backboy and sync with Debian!
[19:21]  * sebner hugs RainCT 
[19:21] <sebner> *badboy even
[19:21] <sebner> xD
[19:22] <RainCT> sebner: Don't you have something more interesting to do than to check whether packages use dh7 or not? ;)
[19:23] <sebner> RainCT: pfff, don't be mean, I noticed the 0.4 upload to maverick and since it's your baby I took a look :P
[19:23] <RainCT> :)
[19:27] <didrocks> sebner: I've proposed to comaintained in Debian :)
[19:27] <didrocks> RainCT: thanks for the team btw
[19:28] <sebner> didrocks: cool .. then you are forced to use dh7 too \o/ :P
[19:28] <didrocks> sebner: well, I used dh7 for some packages. Knowing that I'll synced soon zg again with debian, (0.4.1 I hope), I didn't investigate on the merge now :)
[19:28] <RainCT> didrocks: Np, thanks for your help :)
[19:29]  * RainCT hopes sebner doesn't remember that half of my packages still use CDBS :P
[19:30] <didrocks> RainCT: btw, if you are not aware: bug #597687
[19:30] <didrocks> well, cdbs isn't so bad :)
[19:31] <RainCT> Yeah, it rocks (until it fails awfully and you don't know why :)). But dh7 is much nicer.
[19:31] <sebner> didrocks: hahaaha, good joke. Haven't laughed that much in a while :D
[19:31] <sebner> RainCT: I do ;)
[19:31] <RainCT> dkd
[19:32] <RainCT> * didrocks: Yep seen the MIR. Awesome :D.     Although now this is my second package moving into main :/
[19:33] <didrocks> RainCT: you're not a core-dev? you should upload for per package upload
[19:33] <didrocks> apply*
[19:33] <didrocks> sebner: really, GNOME lives with it for so long :)
[19:34] <didrocks> sebner: it just habits, most of the time, but yeah, dh7 is clean
[19:34] <sebner> didrocks: one of the most sad things, right
[19:34] <didrocks> sebner: we have also to do port the strip translations/desktop.in to dh7
[19:35] <didrocks> but in any case, we will just follow debian packaging, won't create a diff on merge for that
[19:35] <sebner> didrocks: heh, nice. Long long time ago I also wanted to get involved with gnome-packages. After looking at the packages, especially the rules file I decided: "Before I touch this, I'm gonna die" :P
[19:36] <RainCT> By the way, is there anyone maintaining DistUtilsExtra?
[19:36] <didrocks> sebner: that's because you looked at gtk or glib :-)
[19:36] <sebner> didrocks: pff, cdbs is cdbs. I just tell what's going on there and that scares me
[19:36] <didrocks> RainCT: well, pitti is doing it most of the time, I still push some patchs from time to time and want to find more for annoying issues
[19:36] <sebner> *can't tell
[19:37] <RainCT> didrocks: I have a couple patches filed against the upstream project which are feeling very lonely :)
[19:37] <didrocks> sebner: did you look at unity packages? they are not so complicated
[19:37] <didrocks> RainCT: oh really?
[19:37]  * didrocks opens the project view
[19:38] <RainCT> Yep, not sure what they where though. I'd probably have some more but since those got ignored I didn't bother.
[19:39] <didrocks> RainCT: you are talking about bug #510957 ?
[19:39] <sebner> didrocks: that's true but still ..
[19:39] <didrocks> (just seeing this one)
[19:40] <didrocks> sebner: for instance, we will in gnome run autoreconf for most of our package, it's one line in cdbs, I should have a look at how to do that in dh7
[19:40] <RainCT> didrocks: Yup that's one (some Gentoo guy was asking us to move GNOME Activity Journal to autotools because of that -.-), the other is #503026 but I see it isn't a patch just the idea; I can write one if you're going to include it though
[19:41] <RainCT> And I'll try to remember what the other stuff was ;)
[19:41] <didrocks> RainCT: LINGUAS can be an environment variable too it seems?
[19:52] <tumbleweed> shadeslayer: those two patches should be combined into one
[19:52] <tumbleweed> they're the same thing
[19:53] <shadeslayer> tumbleweed: ok.. btw im doing some more work :)
[19:53] <shadeslayer> on the package...
[19:53] <tumbleweed> bonus points for a DEP3 header
[19:53] <shadeslayer> hehe :)
[19:53] <shadeslayer> will do :P
[19:54] <shadeslayer> tumbleweed: any other issues?
[19:54]  * tumbleweed looks
[19:55] <shadeslayer> still have no idea why im getting the changes issues
[19:55] <tumbleweed> description is a bit weird
[19:56] <shadeslayer> tumbleweed: yeah correcting that as well :P
[19:56] <shadeslayer> modified debian/docs as well
[19:56] <tumbleweed> btw quilt patches don't need numbers, the order is defined by debian/patches/series
[19:56] <shadeslayer> tumbleweed: ah ok..
[19:57] <shadeslayer> tumbleweed: watch file isnt working for now :P
[19:59] <tumbleweed> shadeslayer: not that it matters, but you forgot to escape the final . in the watch file
[19:59] <shadeslayer> tumbleweed: uh.. what?
[19:59] <tumbleweed> it's a regex, so a literal . should be written as \.
[20:00] <shadeslayer> tumbleweed: http://qipmsg.googlecode.com/files/qipmsg-(.*)\.tar.bz2
[20:00] <tumbleweed> http://qipmsg.googlecode.com/files/qipmsg-(.*)\.tar\.bz2
[20:00] <NorthernLights> Hello all
[20:00] <shadeslayer> ah
[20:00] <shadeslayer> NorthernLights: hi
[20:01] <tumbleweed> shadeslayer: you probably want to use http://googlecode.debian.net/p/qipmsg/qipmsg-(.*)\.tar\.bz2
[20:01] <shadeslayer> tumbleweed: thats a 404
[20:01] <RainCT> didrocks, sebner: Sorry, my network card was being stupid. What did I miss?
[20:02] <tumbleweed> shadeslayer: that's not how watch files work. read uscan's man page
[20:02] <tumbleweed> shadeslayer: http://googlecode.debian.net/p/qipmsg does not 404
[20:02] <didrocks> RainCT: nothing, I saw that you quit :) I've merge your LINGUAS change btw
[20:02] <didrocks> sorry it took so long
[20:02] <sebner> RainCT: nothing (?) , my network broke down too xD
[20:02] <RainCT> lol
[20:02] <RainCT> didrocks: Cool thanks.
[20:02] <didrocks> oh, that's why it was so quiet :)
[20:02]  * didrocks kidding
[20:02] <didrocks> RainCT: you're welcome, thanks for the patch
[20:02] <shadeslayer> tumbleweed: ah ok
[20:03] <tumbleweed> NorthernLights: I see you posted your synergy+ to debian-mentors@d.o. did you subscribe to the mailing list? (you got at least one reply)
[20:04] <NorthernLights> yep
[20:04] <NorthernLights> I answered
[20:04] <NorthernLights> and invited upstream to comment on it
[20:04] <tumbleweed> NorthernLights: good answer. I was hoping someone would ask you that question
[20:08] <tumbleweed> shadeslayer: oh, um, any reason why you ignored W: qipmsg: extra-license-file usr/share/doc/qipmsg/Copying.txt.gz
[20:08] <shadeslayer> tumbleweed: i removed that
[20:08] <shadeslayer> from debian/docs
[20:08] <tumbleweed> cool
[20:08] <shadeslayer> im sure of it
[20:09] <shadeslayer> no i mean i removed it before the upload
[20:11] <didrocks> nigelb: do you want to rebase the debdiff you posted for bug #111939 or could I just integrate the patch?
[20:11] <didrocks> nigelb: I can do it very quickly, so if you don't mind, I can just copy mcclasen patch and rebase to the last version
[20:16] <shadeslayer> tumbleweed: btw the 2 patches modify 2 different files
[20:16] <shadeslayer> how do i combine them?
[20:17] <tumbleweed> shadeslayer: but they depend on each other. They exist to fix the same problem
[20:17] <shadeslayer> tumbleweed: how do they depend on each other
[20:20] <tumbleweed> shadeslayer: one corrects a spelling mistake, one corrects the translation for the same spelling mistake
[20:21] <shadeslayer> ah
[20:22] <tumbleweed> shadeslayer: hint: it's the upstream's makefile that's installing Copying.txt it also installs another file you don't need
[20:24] <geser> shadeslayer: why not make 1 patch from those two?
[20:25] <fabrice_sp> Is there a page somewhere with the number of package I sponsored?
[20:25] <geser> not that I know of
[20:25] <tumbleweed> geser: yeah that's what I'm suggesting he do
[20:26] <fabrice_sp> geser, ok. I'll check with the launchpad API, because it seems that the data is there
[20:27] <tumbleweed> fabrice_sp: btw, did you read zaytsev's reasoning in Bug #565826
[20:27] <fabrice_sp> tumbleweed, nop. Let me check
[20:28] <geser> fabrice_sp: I guess you would be faster with greping the -changes archive for your name in Signed-By
[20:29] <fabrice_sp> geser, I did that, but actually, I also got all packages I uploaded, and not only the ones I sponsored
[20:30] <fabrice_sp> someone made some script to extract the same info from udd for Debian
[20:30] <fabrice_sp> tumbleweed, what is your opinion about keeping or not the patch? It seems that it can be dropped
[20:30] <fabrice_sp> but the bug report was really that people anted mcedit to be the default at intall time
[20:31] <tumbleweed> fabrice_sp: yeah. it'll irritate the odd person, but they can change it at least
[20:31] <fabrice_sp> s/anted/wanted/
[20:31] <fabrice_sp> tumbleweed, yeah: it doesn't seems to be worth keeping the diff
[20:32] <tumbleweed> ok, I'll ack it
[21:07] <Rhonda> shadeslayer: dversionmangle=s/\+ds// removes the string +ds from the Debian version for comparison. Not sure what that would represent, might be debian source, and then it's only used when stuff got removed from the tarball, not for a simple repack from .tar.bz2 to .tar.gz or similar.
[21:14] <tumbleweed> Rhonda: "debian source" yes
[21:17]  * NorthernLights still tries to ask for a REVU review ;)  . For packages synergy-plus and kill-rogues. Thanks!
[21:17] <NorthernLights> s/kill-rogues/killrogues
[21:18] <tumbleweed> NorthernLights: not waiting to see whether the merge-into-synergy route will work out?
[21:26] <NorthernLights> tumbleweed, i don't how that will go but i'd still like to know what's my package worth.
[21:27] <tumbleweed> looks like that won't be quick anyway...
[21:27] <NorthernLights> yep
[21:27] <NorthernLights> if it goes into a lenghy conversation with synergy author i'll say that proves we need synergy+, even if temporarily
[21:28] <NorthernLights> we still can make a transitional package of synergy laster
[21:28] <Rhonda> tumbleweed: Never had the need to do that, gladly. :)
[21:28] <NorthernLights> later
[22:09] <micahg> is there a trick for regenerating a control file for another version of Ubuntu from Lucid (i.e. w/a debian/control target in debian/rules) or do you need to be in a chroot?
[22:10] <tumbleweed> micahg: generating control files from rules is ugly
[22:10] <soren> micahg: There's nothing version specific in debian/control.
[22:11] <tumbleweed> the version comes from changelog
[22:11] <micahg> soren: there's a control.in file
[22:11] <micahg> I was just wondering if this is a general thing or more specific to the pacakge I'm working with openjdk
[22:12] <tumbleweed> micahg: what problem are you trying to solve?
[22:13] <micahg> tumbleweed: I need to regenerate the control file for jaunty and karmic from the lucid build (it's possible, I just don't know how)
[22:13] <soren> micahg: ...which generates a control file which doesn't have anything series specific in it.
[22:13] <micahg> soren: yes, but what needs to be in there *is* series specific due to stuff in debian/rules
[22:14] <soren> micahg: The only reference to series is in the changelog and the changes file.
[22:14] <ajmitch> different xulrunner dependencies?
[22:14] <micahg> soren: nm, I'll just go ask dokko
[22:14] <micahg> *soko
[22:14] <micahg> *doko
[22:14] <soren> micahg: Can you explain what it is that needs to vary depending on series?
[22:16] <anoteng> anybody know if dh_python2 is in maverick?
[22:16] <micahg> soren: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk6/annotate/head:/rules
[22:17] <tumbleweed> anoteng: not yet
[22:17] <anoteng> mkay, guess I'll have to install sid then…
[22:18] <soren> micahg: Yikes.
[22:18] <soren> micahg: That's all I have to say.
[22:18] <micahg> soren: right :)
[22:19] <ScottK> anoteng: It's only partly in.  It will be shortly.
[22:43] <jono_> Laney, ping?
[22:49] <gaston_> can anyone tell me where can I find the .deb files naming convention?
[22:50] <gaston_> I can't find it in the MOTU wiki, thank you
[22:54] <tumbleweed> gaston_: the debian policy manual covers some of it
[22:59] <gaston_> ok, found that, thanks
[23:31] <jono> Laney, ping?