[00:03] <pochu> ScottK2: what would happen if upstream doesn't have a ChangeLog/NEWS file? Would a diff of the upstream source be ok?
[00:04] <ScottK2> I'd rather you read the diff and sumarize what you think the changes are than you make me do it.
[00:05] <pochu> ScottK2: hmm, right. It's just in case I need to do it, as stani doesn't have one ;)
[00:21] <james_w> geser: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460362 seems to have fixed it. At least it builds on current hardy.
[00:21] <ubotu> Debian bug 460362 in binutils-avr "binutils-avr: FTBFS: Applying patch debian/patches/dollars.patch failed!" [Serious,Fixed]
[00:23] <james_w> geser: shall I request the sync?
[00:28] <TheMuso> ScottK2: I just added ubuntustudio to that page, thanks for the pointer to it.
[00:31] <emgent> heya *
[00:36] <bddebian> Hello emgent
[00:36] <emgent> :)
[00:41] <ScottK> TheMuso: Did motu-release give a standing FFe to ubuntu-studio this time around?
[00:42] <TheMuso> ScottK: I don't know, but ubuntustudio was given one last cycle
[00:42] <ScottK> TheMuso: I think it's fine that they have one myself, but we have new people on the team, so I think it should be asked each cycle.
[00:43] <TheMuso> Fair enough
[00:43] <TheMuso> I know Hobbsee was fine with it.
[00:43] <TheMuso> I'll ping norsetto and sistpoty when they're around alter.
[00:44] <ScottK> TheMuso: Perhaps a bug with also affects for the relevant packages would be the best way?  That way there's no confusion.
[00:44] <TheMuso> Right.
[01:04] <netzmeister> slomo_, ping
[02:02] <james_w> nxvl: hi. I've just realised it's our talk tomorrow (in my TZ at least). I've got to sleep now, but I'll send you some notes in a few hours.
[02:03] <nxvl> james_w: ok, for me it's past tommorrow :D
[02:04] <james_w> ah, you've got longer to prepare then :)
[02:09] <nxvl> james_w: kind of
[02:09] <nxvl> i'm at gmt-5
[02:18] <rmjb> Hello all
[02:19] <rmjb> just looking for a little advice on how you all handle python programming, on an individual level...
[02:19] <rmjb> for those of you that read dive into python that is
[02:22] <jdong> is this the right place?
[02:24] <rmjb> well it's not a motu question, but I just wanted to get some advice on how you all work as individuals... it's not a python question per se but more a personal style question
[02:24] <rmjb> I'm dragging it out too long
[02:25] <rmjb> do any of you find "dive into python" a good reference book to go back to after you've read it through once?
[02:25] <rmjb> oh and happy new year to anyone that recognizes me... I've not been in here in ages
[02:26] <jdong> rmjb: I've read bits of it, and I think it's a good python book but not a good reference
[02:28] <rmjb> yeah me too, it doesn't seem to be... I want to support the author, but I guess I wont buy the book
[02:28] <jdong> I like the Python Cookbook as a purchased python book
[02:28] <jdong> it's just a huge library of examples, worth looking at time and time again
[02:28] <persia> Using package (>= version~) as a dependency or build-dependency is a workaround to also allow backported versions to meet the dependency.
[02:29] <jdong> yes.... yes it is. but *looks at scrollback*
[02:29] <rmjb> jdong, cool, I'll look at that one when I'm finished with this one. Thanks
[03:18] <LaserJock> Fujitsu: have you looked at octave3.0 lately?
[03:19] <nixternal> ahh, LaserJock just who I wanted to bug :)
[03:19] <LaserJock> nixternal: regarding PG?
[03:19] <nixternal> haha ya
[03:19] <nixternal> stupid ass LP
[03:20] <koolkat> what is MOTU?
[03:20] <LaserJock> Masters of the Universe
[03:20] <LaserJock> maintainers of Universe and Multiverse repositories of Ubuntu
[03:20] <nixternal> masters of the universe...universe being the repositories we maintain
[03:20] <nixternal> ya, I forget about multiverse repos, only cuz I don't work on anything in them...
[03:20] <LaserJock> pfft
[03:20] <nixternal> err, except the openttd upload I did I guess
[03:21]  * persia stresses "Masters", as there are many non-MOTU maintainers of universe software
[03:21] <koolkat> what skills do I need?
[03:21] <nixternal> a couple
[03:22] <nixternal> like, being able to compile software
[03:22] <koolkat> like what?
[03:22] <LaserJock> koolkat: patience mostly
[03:22] <nixternal> hunt out application dependencies
[03:22] <LaserJock> :-)
[03:22] <nixternal> patience like LaserJock said, and a lot of it :)
[03:22] <koolkat> LaserJock: that seems easy
[03:22] <koolkat> :-)
[03:22] <nixternal> obviously you have the english language down :)
[03:22]  * koolkat thinks about joining
[03:22] <nixternal> debian packaging
[03:23] <nixternal> how to efficiently drink beer and dance while building a package...simultaneously I might add :)
[03:23] <koolkat> uhhh....about the packaging part.....is it hard?
[03:23] <nixternal> if I can do it, anyone can
[03:23] <nixternal> then again, who is to say I can even do it
[03:23] <koolkat> where do I learn?
[03:23] <nixternal> I just play like it
[03:24] <nixternal> http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd
[03:24] <nixternal> err
[03:24] <nixternal> that isn't going to help
[03:24] <nixternal> https://wiki.ubuntu.com/PackagingGuide
[03:24] <nixternal> that will though :)
[03:24] <nixternal> obviously I was working on some docs...much earlier though..odd that was still in my klipper
[03:25] <LaserJock> nixternal: ok, so about the PG bugs
[03:25] <nixternal> seems there are only 3 of them
[03:25] <LaserJock> some of the could be closed already
[03:26] <koolkat> nixternal: do are you a member?
[03:26] <koolkat> so*
[03:26] <nixternal> ya, I was thinking the same, with a reference that it has been moved to the wiki and is no longer a package
[03:26] <LaserJock> I count 8 bugs
[03:26] <nixternal> koolkat: yes I am
[03:26] <nixternal> err, where did I miss 5 of them
[03:26] <LaserJock> nixternal: you have to look at both the ubuntu-docs package and project
[03:27] <superm1> TheMuso, with these changes to the seeds, how do you *not* include stuff from hardy.platform?
[03:27] <superm1> there is lots of stuff in there that we dont want
[03:27] <nixternal> ahh ya, the project
[03:27] <nixternal> is there going to be a rewrite or something of the PG on the wiki?
[03:27] <LaserJock> nixternal: what do you mean?
[03:28] <nixternal> LaserJock: I think what I will do, is close the bugs, take out the contents, and add them to the Maintenance page of the PG on the wiki
[03:28] <nixternal> LaserJock: nevermind, I was thinking of something else
[03:28] <LaserJock> nixternal: yeah, we might do that
[03:28] <LaserJock> it'd be nice if we had a way to deal with the bugs
[03:28] <nixternal> I can do that really quick
[03:28] <nixternal> well it is on the wiki now, so maybe adding a section to the Maintenance page for people to file an issue
[03:29] <koolkat> nixternal: what are the tasks that you do?
[03:29] <koolkat> in MOTU?
[03:29] <LaserJock> nixternal: yeah, that makes sense
[03:29] <nixternal> koolkat: I mostly help maintain Kubuntu/KDE packages, but I also help others with packaging when they need it, and help anyway I can
[03:29] <nixternal> really don't have a "single" task perse
[03:30] <nixternal> LaserJock: OK, I will finish that up right now then
[03:30] <koolkat> what do you mean by "maintain"
[03:30] <LaserJock> nixternal: thanks
[03:31] <koolkat> nixternal: what do you mean by "maintain"
[03:32] <LaserJock> generally things like making sure we're updated, incorporating bug fixes
[03:32] <persia> koolkat: There are three main thrusts of activity: fixing bugs in the software, making sure that all the software works together, and making sure the software is mostly up to date.  The third part is done for hardy, but the first two would benefit from your assistance.
[03:32] <koolkat> I guess I could join...i think
[03:33] <koolkat> i hope
[03:33]  * koolkat worries
[03:33] <persia> koolkat: Best way to start is to find a couple bugs that need fixing, prepare patches, and submit debdiffs of new candidate revisions.  See https://wiki.ubuntu.com/MOTU/Contributing.
[03:34] <koolkat> persia: Is there a specific place to join MOTU?
[03:35] <persia> koolkat: Joining MOTU is not really the first step.  Only about 1/3 of the people who have uploaded packages to hardy are MOTU.  You'll want first to be a Contributor, and if you are dilligent and active, you will be encouraged to apply for MOTU.
[03:35] <koolkat> Oh
[03:36] <nixternal> bug 116757
[03:36] <ubotu> Launchpad bug 116757 in ubuntu-docs "Packaging Guide not clear on "rules" having to be executable" [Low,Invalid] https://launchpad.net/bugs/116757
[03:36] <nixternal> ahh, that's teh link :)
[03:36] <persia> koolkat: On the MOTU/Contributing page there are links to some of the teams that you might want to join to start the process.
[03:37] <koolkat> are there anyother projects that need more people?
[03:37] <persia> nixternal: Is that really a bug?  debuild/dpkg-buildpackage set executable anyway, even if it wasn't that way when they were called.
[03:37] <nixternal> persia: I will check it out further after I finish moving them
[03:37] <nixternal> not necessarily a bug maybe, but unclear to someone obviously
[03:38] <persia> Makes sense.
[03:38] <LaserJock> koolkat:  the actual MOTU can upload any package in Universe and Multiverse and requires a lot or trust and experience. There are only 80 MOTU
[03:38] <persia> koolkat: There surely are other projects that also need more people, but we'll all encourage you to participate in universe work, as that's what we do :)
[03:38] <LaserJock> koolkat: contributing to Ubuntu though is fairly easy and defiantly encouraged
[03:39] <koolkat> In motu what should I start out doing?
[03:40] <LaserJock> nixternal, persia: some people actual were getting errors I believe because of the rules thing
[03:40] <koolkat> I dont know that much(or if any) programming.....i think thats bad
[03:40] <LaserJock> koolkat: well, do you have an interest in a particular area of software?
[03:40] <LaserJock> koolkat: many don't when they start
[03:40] <persia> LaserJock: It prints a message complaining about it, but it fixes it when it complains.  Maybe better to change the language of the warning then to make everyone try to remember chmod +x debian/rules
[03:40] <koolkat> what do you mean?
[03:41] <koolkat> LaserJock: What do you mean?
[03:41] <LaserJock> koolkat: I didn't know how to program when I started contributing
[03:41] <LaserJock> I still don't know much ;-)
[03:41] <persia> koolkat: Assuming you run Ubuntu, which are your favorite pieces of software, and which are your most annoying bugs?  Those are typically good places to start.
[03:41] <koolkat> I like firefox
[03:41] <LaserJock> persia: how long has that been? seems like people complained about it erroring out
[03:42] <LaserJock> maybe it was just a complaint
[03:42] <koolkat> I like gimp also...
[03:42]  * koolkat confused
[03:42] <LaserJock> hehe, pick the easy ones :-)
[03:42] <persia> It reports an error, but it doesn't stop the process.  Looking for the change now (as I don7t ever remember it being a new feature).
[03:43] <LaserJock> koolkat: for Firefox Ubuntu has a whole Mozilla Team
[03:43] <koolkat> Thats what i figured
[03:43] <LaserJock> they always like help :-)
[03:44] <koolkat> Where do i go for that?
[03:44] <persia> koolkat: For working with Firefox and related packages, you might want to check for things need doing on #ubuntu-mozillateam.  For gimp, https://launchpad.net/ubuntu/+source/gimp/+bugs is a list of things to do.
[03:45] <koolkat> Ill try to work with gimp
[03:45] <koolkat> firefox probably has alot of people
[03:45] <LaserJock> koolkat: actually, basically *any* area of Ubuntu needs help
[03:45] <LaserJock> there's always things needing doing
[03:45] <LaserJock> even if it's testing and bug triage
[03:46] <persia> koolkat: There's also a lot of firefox work: lots of packages need adjustment to work well with the newest firefox, and there are lots of other xulrunner applications they handle.  On the other hand, gimp always appreciates love.
[03:46] <koolkat> So I if contribute anywhere and I am deemed useful I will hopefully eventually become a MOTU?
[03:46] <LaserJock> koolkat: also note that Firefox and Gimp are in Main, not Universe
[03:47] <persia> LaserJock: I believe the "must be executable" warning comes from pkg 0.93.9 (from 1994).
[03:47] <koolkat> Oh....
[03:47] <LaserJock> koolkat: that's fine of course
[03:48] <LaserJock> it's just not MOTUs specific responsibility
[03:48] <persia> koolkat: Exactly.  It was about two years for me, but some people become MOTU in as little as six months.  It depends on how much time you have, and how much work you do.
[03:48] <koolkat> persia: even if i contribute to firefox?
[03:49] <koolkat> I have ALOT of time
[03:49] <LaserJock> heh
[03:49] <persia> koolkat: Likely.  If you have an interest in FireFox, you'll probably expand to helping work on all the different applications that work with firefox, and a number of them are in universe.
[03:49] <koolkat> Is chatzilla in the universe?
[03:50] <persia> koolkat: We call it "seamonkey-chatzilla", but yes.  You can always get the answer to that question with `rmadison -u ubuntu $(package)`
[03:51] <koolkat> I have to boot to my ubuntu partition.....so ill be back
[03:55] <koolkat> IM BACK....!!
[03:56] <koolkat> So .......what do I do again....to get into the bugs stuff?
[03:58] <koolkat> anyone?
[03:59] <nixternal> whew, that was a lot of copying/pasting...there were a total of 10
[03:59] <nixternal> and LaserJock left
[04:00]  * koolkat lauges
[04:00] <nixternal> koolkat: https://wiki.ubuntu.com/MOTU  <- you will probably find a good deal of the answers you are looking for from that page and its subpages..there is a bugs page somewhere in there :)
[04:01] <nixternal> bbiaf, gotta catch the news
[04:02] <koolkat> an launch pad I joined the "Contributors of packages for ubuntu universe" thingy
[04:05] <persia> koolkat: Welcome.  I'd recommend also joining the bugsquad (see #ubuntu-bugs), and subscribing to the ubuntu-devel@, ubuntu-devel-announce@, and ubuntu-motu@ mailing lists.
[04:07] <koolkat> I joined.... :-)
[04:08] <koolkat> So eventually.....if i contribute alot.....ubuntu will invite me to be a MOTU?
[04:09] <persia> Excellent.  Now you just need some bugs to hunt.  https://bugs.launchpad.net/ubuntu/+bugs lists a for you to examine.
[04:10] <persia> Yes.  After a while of working on the packages, people will start telling you to apply.  Once you have enough sponsors prepared, you can submit an application.  For now, better to concentrate on the actual bugs.
[04:11] <ember> talking about gimp..
[04:11] <ember> can someone from main take a look at bug #189758
[04:11] <ubotu> Launchpad bug 189758 in gimp "[hardy] Menu entry should be named "GIMP Image Editor" Instead of only the "GNU Image Manipulation Program"" [Wishlist,Confirmed] https://launchpad.net/bugs/189758
[04:13] <koolkat> persia: how do I know how to fix a bug?
[04:17] <persia> koolkat: That's the fun part.  Based on the bug, examine the application and the source code, and read various documentation to fix it.  Once you've hunted a couple, you'll have some solutions you know, and can apply that to other packages.  The first one can be a little tricky, but ember's example is good: demonstrating a fix for a bug.
[04:17] <persia> ember: All the right people are subscribed & assigned.  You just have to wait for a -desktop sponsor.
[04:18] <koolkat> persia: what do I read?
[04:19] <persia> koolkat: Depends on the bug.
[04:19] <koolkat> Ok...for example on this link https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/186345 what would i read to try to fix it?
[04:19] <ubotu> Launchpad bug 186345 in gimp "histogram disappears in gimp's curves tool" [Low,New]
[04:20] <persia> ember: Actually, looking at that bug, the updated .desktop file isn't valid.  Please patch it harder so that desktop-file-validate doesn't complain.
[04:20] <persia> koolkat: Do you understand the problem, and why the graph doesn't appear?
[04:21] <koolkat> uh....let me think......no
[04:22] <ember> my bad persia i forgot to follow fd.o
[04:23] <Fujitsu> ember: Also, the application's name is not GIMP, but The GIMP.
[04:23] <persia> koolkat: in that case, I'd start by reading about GNOME theme definitions, and looking at the gimp code (especially the file mentioned) to understand how the graph could disappear.  After you have an understanding, you will likely have developed some pointers to other documentation suggesting possible fixes.  Once you have a couple candidates, you can check with upstream to see which would be the least intrusive, and submit that.
[04:25] <ember> Fujitsu looking at the old patches the change is from The Gimp to GIMP image editor.
[04:26] <blueyed> koolkat: you can get the gimp source with "apt-get source gimp". Then you could try to find the place where the theme colors get used. Then add a check there if they are the same and use others instead.
[04:26] <Fujitsu> ember: Well, that's probably wrong.
[04:27] <Fujitsu> I'd say `The GIMP Image Editor'
[04:27] <koolkat> I think that i shouldnt of joined.....i know some c++ for Win 32 API but this stuff is confusung
[04:28] <persia> The GNU Image Manipulation Program Image Editor seems just odd :)
[04:28] <ember> Fujitsu well that's "THE" is odd on desktop files and stuff
[04:28] <Fujitsu> persia: It does, true.
[04:28] <ember> you don't see "The Text Editor"
[04:28] <ember> and etc
[04:28] <Fujitsu> ember: Most applications don't have `The' at the start of their names.
[04:29] <Fujitsu> The GIMP does.
[04:29] <blueyed> koolkat: then just look at another bug, something easier.
[04:29] <koolkat> Ugh :-|
[04:29] <persia> koolkat: There are lots of easier bugs.  Take a look at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize or https://bugs.launchpad.net/ubuntu/+bugs?field.tag=packaging or https://bugs.launchpad.net/ubuntu/+bugs?field.tag=desktop-file
[04:30] <koolkat> ill try
[04:30] <ember> Fujitsu where?
[04:31] <Fujitsu> Hmm, I know it used to be the policy that it must be prefixed with `The', but their website seems to indicate otherwise now.
[04:31]  * persia thinks they gave up correcting people
[04:49] <danielm> where patches are submited? launchpad?
[05:28] <persia> danielm: Yes
[05:59] <AnAnt> persia: regarding bug #191662 what fix is committed ?
[05:59] <ubotu> Launchpad bug 191662 in ubuntume-gdm-themes "New package for ubuntume-gdm-themes" [Wishlist,Fix committed] https://launchpad.net/bugs/191662
[06:00] <persia> AnAnt: It means it got uploaded.  The next step is "Fix Released", which means it is closed.
[06:00] <AnAnt> persia: uploaded where ? to the queue ?
[06:01] <AnAnt> persia: btw, do you know why new upstream versions of gpm aren't packaged  (not even in Debian) ?
[06:01] <persia> AnAnt: To Soyuz.  Once uploaded, it gets put in one of the queues by the upload processor (usually takes a few minutes), and then, depending on the queue, it may be a manual or automatic process to get into the repositories.
[06:02] <persia> And, no, I don't know anything about gpm packaging
[06:59] <warp10> Good morning
[07:30] <LucidFox> How do I exclude a single library from being added to dependencies by dh_shlibdeps?
[07:30] <LucidFox> (specifically, this is to be able to explicitly depend on libxine1-x | libxine1)
[07:38] <persia> LucidFox: For that special case, duplicated dependency on libxine1 is acceptable.
[07:39] <LucidFox> Hmm, but libxine1 pulls all the unneeded stuff, including libxine1-x
[07:40] <LucidFox> Or will it be changed after the migration is complete?
[07:42] <persia> It oughtn't.
[07:42] <persia> Ah.  Right.  I requires libxine1-x, but not xineui.  Hmmm..
[07:44] <persia> Aha.  libxine1-x depends on libxine1-bin.  libxine1 is the thing that shouldn't be required anymore.
[07:47] <LucidFox> Indeed. I looked at what you did for codeine, but it depends on both libxine1-x and libxine1.
[07:48] <LucidFox> as does klear
[07:53] <persia> Maybe once the transition is complete, the libxine-dev shlibs file can be changed.
[09:57] <siretart> libxine1-x dependency will be dropped after lenny is released
[09:58] <siretart> I'd like to keep it at least for hardy for dapper->hardy upgrades.
[09:59] <persia> siretart: So hardy release will be mid-way through the transition?  If we upload a few things, can we push it all the way for Ubuntu, and catch up later?
[10:05] <siretart> persia: which transition are you talking about?
[10:06] <persia> libxine1 -> libxine1-bin
[10:06]  * siretart confused
[10:07] <siretart> but I just woke up, so...
[10:10] <persia> siretart: LucidFox was looking at the leftovers of bug #159338, and noticed that it generated a double-dependency.  Maybe that is right, but if there is anything we can do to make hardy clean, I'd like to do that, just so we don't have too many leftovers for the next LTS.  You certainly know the code best thought.
[10:10] <ubotu> Launchpad bug 159338 in oxine "Re: Heads-up: small xine-lib transition in hardy" [Undecided,In progress] https://launchpad.net/bugs/159338
[10:10] <persia> s/thought/though/
[10:12] <siretart> persia: LucidFox: the duble dependency is absolutely correct, no problem here
[10:12] <geser> james_w: yes, you can file a sync request
[10:12] <siretart> however, the packages need to manually depend on either libxine1-console or libxine1-x, whatever they actually need
[10:13] <siretart> perhaps -ffmpeg, if they need to play mp3 files
[10:13] <LucidFox> siretart> but if a package depends on both libxine1 and libxine1-x, then libxine1 pulls libxine1-x AND libxine1-console and a ton of other stuff
[10:13] <LucidFox> which is, from what I can discern, is precisely what everyone was trying to avoid
[10:13] <persia> siretart: The thing being that libxine1 depends on libxine1-x and libxine1-console, so these parallel dependencies aren't actually used.
[10:19] <james_w> geser: thanks for the ack.
[10:24] <Tonio_> hello
[11:21] <Tonio_> someone here to that one ? http://revu.tauware.de/details.py?package=kdesudo-kde4
[11:22] <Tonio_> very important on the kubuntu/kde4 side !
[11:23] <persia> Tonio_: Have you filed a freeze exception?
[11:28] <Tonio_> persia: nope, I'm waiting for the packaging to be accepted before filing this ;)
[11:39] <warp10> I'm rebuilding grisbi for libofx3 -> libofx4 transition. Current version is 0.5.9-0ubuntu1, but Maintainer has not been set to MOTU. Should I set it now?
[11:41]  * stdin sees "Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>" in grisbi 0.5.9-0ubuntu1
[11:41] <warp10> stdin: Where did you see that?
[11:42] <stdin> warp10: from 'apt-cache show grisbi'
[11:43] <warp10> stdin: mmm... weird. I downloaded the source, and debian/control has a field Maintainer: Benjamin Drieu <benj@debian.org>
[11:44] <emgent> heya norsetto :)
[11:45] <norsetto> hiya all
[11:45]  * norsetto bows to the master of security
[11:45] <stdin> warp10: hmm, you're right
[11:45] <warp10> ciao norsetto! good to see you around
[11:45] <norsetto> stdin: warp10 is always right
[11:46] <stdin> warp10: wouldn't do any harm to set it correctly now anyway
[11:46] <warp10> norsetto: heh :)
[11:46] <warp10> stdin: indeed. Anyway, I'm wondering how this can happen
[11:47] <persia> stdin: warp10: The binary package carries the restrictions, as it gets set by the pkgbinarymangler script on the buildds.  The source package needs to be updated.
[11:47] <stdin> I think one of the many scripts the buildd runs can check if the maintainer has an ubuntu.com address
[11:47] <stdin> ah, so I was mostly right in my assumption there :)
[11:48] <persia> stdin: Completely right, just missing the package name :)
[11:48] <warp10> persia, stdin: Ok, I'll update the debian/control therefore
[11:49] <persia> warp10: There are about 100 other packages that need that sort of attention as well.  Patches appreciated.
[11:49] <persia> Tonio_: Examining the package now, but you'd do best to get your FFe approved as soon as possible.  Once approved, the upload can always happen a bit later.
[11:50] <Tonio_> persia: sure, but I plan to release a tarball in between as we are also maintaing the code
[11:51] <Tonio_> persia: reviewing is another way to get something clean on kde-apps :)
[11:51] <persia> Tonio_: Then my current review is fairly pointless :)
[11:52] <warp10> persia: are you speaking about packages needing a transition or about the maintainer issue?
[11:52] <persia> warp10: Maintainers
[11:52] <warp10> persia: any tool to find them all?
[11:54] <persia> warp10: wget -O - http://archive.ubuntu.com/ubuntu/dists/hardy/universe/source/Sources.gz| gunzip | grep-dctrl -sPackage,Maintainer -FVersion ubuntu  | grep-dctrl -sPackage -FMaintainer -v -n ubuntu | sort -u
[11:54] <persia> 183 pending today
[11:56] <warp10> persia: Good. I'll try to shorten the list.
[11:57] <persia> warp10: Thank you.  For every package in that state, we're not complying with our agreement with Debian about variation.
[11:58] <persia> Note that most of them haven't been touched in a while, and would probably benefit from other things, like menu file transition, .desktop cleanup, etc.
[12:01]  * norsetto -> lunch
[12:01] <persia> Tonio_: Your package doesn't build in hardy.
[12:01] <warp10> persia: Indeed! I'll try to find out what every package need and fix accordingly
[12:02] <Tonio_> persia: hu ??????
[12:02] <Tonio_> persia: lemme check..... I was asked to update the cdbs content, maybe that causes the issue
[12:02] <persia> That would be it.  Fails to find /usr/share/cdbs/1/rules/patchsys-quilt.mk, which points at a missing build-dependency.
[12:03] <Tonio_> ah......
[12:03] <Tonio_> so stupid....... I don't use patches so removed quilt from builddeps
[12:03] <Tonio_> that's a cdbs files issue
[12:03] <persia> Tonio_: Testing is key :)
[12:04] <jpatrick> Tonio_: blame debian-qt-kde
[12:04] <Tonio_> jpatrick: I do, I HATE quilt !
[12:04]  * jpatrick hugs Tonio_ 
[12:05] <persia> Shouldn't whatever is including that depend on quilt so that the packages don't need to do so individually?
[12:05] <Tonio_> jpatrick: what's better ? changing cdbs files or adding a stupid builddep to override ?
[12:05] <Tonio_> jpatrick: I think the builddep is better, as I won't have to consider changing cdbs files everytime
[12:05] <jpatrick> Tonio_: I just suffer and add quilt to build dep
[12:05] <Tonio_> persia: it'll be fixed on revu in a few minutes
[12:06] <jpatrick> persia: some of the debian-qt-kde guys have a thing for quilt
[12:06] <persia> jpatrick: No issue with that, but isn't there some package that provides the CDBS snippets?  That package ought depend on quilt.
[12:08] <jpatrick> persia: personally I have no idea why quilt is needed
[12:09] <persia> Because the recommended CDBS bits include the quilt.mk which means it FTBFS without quilt even when quilt isn't being used.
[12:10] <Tonio_> persia: you can review again, should be okay this time
[12:10] <Tonio_> jpatrick: because quilt is horribly powerfull and complex
[12:11] <Tonio_> jpatrick: exactly what debian likes :)
[12:11] <persia> Tonio_: I'm going to bed, and I don't see the point of a review when there will be a new upstream before it gets accepted and there's no FFe.
[12:11] <jpatrick> Tonio_: well, I've always perfered simple-patchsys
[12:11] <Tonio_> jpatrick: of course now quilt is there, there is absolutly no way to use simple-patchsys, it won't be able to do the job....
[12:11] <Tonio_> persia: I'm upstream maintainer
[12:12] <Tonio_> persia: so there won't be another upstream release ;)
[12:18] <LucidFox> What advantages does quilt have over dpatch, apart from not using non-standard headers?
[12:19] <persia> It's a little easier to avoid patch conflicts with quilt, because it's a little smarter about these things.
[12:24] <albert23> I have a package (gcal) that built fine a week ago, but now fails, see http://pastebin.ubuntu.com/4681/. CFLAGS from debian/rules are now passed to configure and make it fail, which didn't happen with the old dpkg.
[12:24] <albert23> Downgrading dpkg to the old version solves the problem. With the new dpkg I have to remove the single quotes from CFLAGS='-O2 -Wall $$(INC) -pg'
[12:24] <albert23> Is that a bug in dpkg or is it a bug in gcal that now became visible?
[12:25] <RainCT> Hey
[12:28] <persia> albert23: It's a bug in gcal unless you can find more than 20 packages that now FTBFS, in which case it becomes a bug in dpkg for now, and a bug in gcal for hardy+1.
[12:30] <albert23> persia: ok, then I will make an update for gcal
[12:47] <james_w> Hi. Could someone clarify a couple of points about imports from Debian for me please?
[12:47] <james_w> firstly are new packages in Debian auto-synced? Or do they require a sync request the first time?
[12:48] <RainCT> james_w: they are auto-synced before DebianImportFreeze starts
[12:49] <james_w> RainCT: thanks. You've answered my second question as well.
[12:49] <RainCT> james_w: and after DebianImportFreeze they require a manual request (and right now for Hardy they would also require a Freeze Exception as there is Feature Freeze)
[12:49] <RainCT> heh
[12:51] <james_w> Would it be correct to say that a synced package has no changes made to it in Ubuntu.
[12:51] <Nafallo> yes
[12:51] <james_w> I guess things like pkg-striptranslations kind of break this don't they?
[12:51] <james_w> and is Maintainer automatically changed for syncs?
[12:52] <Nafallo> not sure I'm involved heavily enough to answer any more.
[12:54] <james_w> the answer to the second part is yes according to https://wiki.ubuntu.com/DebianMaintainerField
[12:54] <Nafallo> pkg-striptranslations were only for main last time I checked, which was ages ago.
[12:57] <james_w> I've gone with "the source package is just rebuilt in the latest development version of Ubuntu. Any changes that are made are purely automated."
[12:57] <persia> There have been slips in the past.  Check your buildlog to be sure.
[12:58] <james_w> I'm only talking in general, so I'll ignore any mistakes.
[13:06] <geser> james_w: during the sync the source package is taken as is from Debian (and stays unmodified)
[13:07] <geser> the maintainer change, pkgstripstranslation and pkg-create-dbgsym only happen during build of the binary debs (and also only affect them).
[13:08] <james_w> geser: thanks.
[13:13]  * norsetto <- lunch
[13:18] <LucidFox> warp10, thanks for opting to take care of the libofx transition!
[13:22] <RainCT> asac: ping
[13:40]  * RainCT is looking for something to do
[13:43]  * maikeru is looking for lunch
[13:44] <jpatrick> RainCT: fix bug #1
[13:44] <ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
[13:44] <RainCT> :D
[13:54] <warp10> LucidFox: my pleasure! grisbi builds fine, now I'm checking the others
[14:14] <warp10> LucidFox: kmymoney2 has been rebuilt two days ago, so it got libofx4 already. (http://people.ubuntu.com/~ubuntu-archive/NBS/libofx3)
[14:25] <shirish> hi all, I want to file  a feature-freeze exception, I have a question about a command.
[14:26] <shirish> This is the command given in the wiki of feature freeze exception process
[14:26] <shirish> diff -ruN <package>-{old-version,new-version} | diffstat > diffstat.txt
[14:26] <shirish> warp10: if u can help me it would be nice.
[14:26] <geser> shirish: what question do you have?
[14:27] <shirish> now I have 2 upstream tarballs which are both .tar.gz , now do I need to gunzip both of them to different directories or how?
[14:28] <warp10> shirish: I'm sorry, I'm going away for a while. I'm sure someone else can help you
[14:28] <geser> shirish: usually they should unpack to different dir names but you can check before doing it
[14:28] <shirish> geser: right, so the first thing is to unpack them to different directories right?
[14:29] <shirish> geser: the tarballs are swfdec-0.5.5.tar.gz & swfdec-0.4.5.tar.gz
[14:29] <geser> shirish: yes, and usually the tar.gz already create a subdir
[14:40] <slicer> Does PPA not support multi-package packages? (ie: one source package produces several different binary packages).
[14:41] <jpatrick> slicer: yes it does
[14:42] <slicer> jpatrick: Odd. I can see both packages being built in the buildlog, but only the first is put in my archive.
[14:42] <jpatrick> slicer: prehaps it's lagging
[14:43] <slicer> jpatrick: Indeed it is. It just appeared now :)
[14:50] <shirish> geser: are u there m8?
[14:50] <geser> yes
[14:50] <shirish> geser: I have untarred both the upstream versions, now how I do run the command
[14:51] <shirish> geser: both are in different directories
[14:51] <shirish> diff -ruN <package>-{old-version,new-version} | diffstat > diffstat.txt
[14:51] <james_w> shirish: diff -Nru swfdec-0.4.5 swfdec-0.5.5 | diffstat
[14:51] <geser> I assume the dirs are named swfdec-0.4.5 and swfdec-0.5.5
[14:51] <shirish> geser: yes, right.
[14:52] <shirish> what is Nru for?
[14:52] <shirish> geser: or it should be ruN
[14:52] <geser> man diff: -N: also diff new files, -r: recursive, -u: unified diff
[14:52] <geser> the order of the options doesn't matter
[14:53] <Nafallo> run is easier to remember :-)
[14:53] <pochu> alias diff='diff -ruN' is even easier :)
[14:54] <geser> shirish: and <package>-{old-version,new-version} expands to <package>-old-version <package>-new-version
[14:55] <shirish> right
[15:10] <dcordero> hi
[15:10] <netzmeister> hi
[15:23] <bobbo> Could a MOTU have a look at http://revu.tauware.de/details.py?package=torrentinfo ?
[15:25] <jpatrick> !nickspam > UbuCat_
[15:26] <UbuCat_> oops :P
[15:32]  * RainCT > comments(bobbo)
[15:34] <RainCT> bobbo: are you upstream?
[15:34] <bobbo> RainCT: no
[15:34] <RainCT> ah I see
[15:35] <protonchris> It was recommended to me that I add a get-orig-source target to a package.  Can anyone in here point me to an example or documenation for that target?
[15:35] <bobbo> RainCT: its my first proper packaging attempt so ive probably done some bits wrong
[15:36] <RainCT> bobbo: was it intended to be a native package?
[15:36] <RainCT> s/was/is
[15:36] <bobbo> RainCT: no
[15:39] <hellboy195> jono our community hero is here :P
[15:39] <jono> hellboy195:  :)
[15:41] <hellboy195> jono: btw, I'm also trying to become a MTOU *awaitingforjonoscongratulations* but I hope it's ok that I don't want to expose me like Efrain Valles
[15:41] <hellboy195> s/me/myself
[15:55] <RainCT> bobbo: http://revu.tauware.de/details.py?package=torrentinfo you've a bit of work :)
[15:56] <RainCT> bobbo: also, if you haven't noticed it, there is Feature Freeze now (no new packages can get into Hardy unless you get an exception)
[16:00] <bobbo> RainCT: so all packages now go into Hardy+1?
[16:03] <jpatrick> bobbo: no, hardy+1 is not yet opened
[16:08] <geser> bobbo: the packages currently on REVU will wait till hardy+1 is open for development, so don't expect a quick review
[16:10] <RainCT> geser: already reviewed ;)
[16:14] <emgent> gentoo #203265
[16:14] <emgent> ubotu argh
[16:14] <ubotu> Sorry, I don't know anything about argh - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[16:15] <RainCT> protonchris: still want to know about get-orig-source?
[16:17] <protonchris> RainCT: yes, please
[16:19] <RainCT> protonchris: I don't know how good they are, but here you have 2 examples: http://paste.ubuntu.com/4684/
[16:21] <protonchris> RainCT: thanks.  I'll take a look.
[16:43] <netzmeister> hello
[16:43] <netzmeister> Are there reasons why Songbird isn't packaged yet?
[16:45] <crimsun_> netzmeister: see debian #412437
[16:45] <ubotu> Debian bug 412437 in wnpp "ITP: songbird -- desktop Web player, a digital jukebox and Web browser" [Wishlist,Open] http://bugs.debian.org/412437
[16:50] <netzmeister> crimsun_, Everybody want be a Co Maintainer. So i am right if i think that there is no "Maintainer"?
[16:52] <crimsun_> netzmeister: I'm sorry, but I don't understand the context behind that question.  Are you referring to that bug report (in Debian) or to Ubuntu MOTU?
[16:53] <james_w> netzmeister: no, there is a "Maintainer", but you can have more than one person looking after the package. It is even possible to have a team as Maintainer.
[16:54] <netzmeister> crimsun_, sorry for confusing you.
[16:55] <netzmeister> james_w, Thx.
[16:57] <netzmeister> crimsun_, i asked myself why there is no songbird package in feisty, gutsy etc..
[16:58] <Lamego> netzmeister, read the bug reporte
[17:06] <crimsun_> netzmeister: right.  Getting the package into Debian will benefit both Debian and Ubuntu, so that is the preferred mechanism.
[17:07] <netzmeister> crimsun_, okay
[17:28] <jdong> vorian: looks like your beloved KTorrent4 has just released 3.0.0
[17:28] <jdong> you should request a FFe on it
[17:36]  * RainCT is preparing a new ubuntu-dev-tools release for Hardy
[17:37] <hellboy195> RainCT: nice :)
[17:39] <superm1> RainCT, you should add a check to it for if there is a bzr branch and debian/changelog hasn't been committed you can't debuild....
[17:40] <superm1> (while your at it)
[17:40] <superm1> i've been meaning to sort that out for ages :)
[17:40] <netzmeister> RainCT:  What are the changes?
[17:43] <RainCT> netzmeister: more or less this http://paste.ubuntu.com/4688/plain (I'm sorting out the biggest changes from the branch)
[17:43] <RainCT> superm1: what do you mean?
[17:43] <superm1> RainCT, well all too often people will go and upload changes without committing them to the branch
[17:43] <superm1> so a check to make sure that if VCS-Bzr or VCS-Git etc are set
[17:44] <superm1> then make sure that changelog is committed there
[17:47] <RainCT> superm1: where..?
[17:47] <superm1> RainCT, well i guess thinking more about it, that is probably more appropriate for devscripts
[17:47] <superm1> nvm :)
[17:49] <RainCT> superm1: mustn't that go into dpkg-buildpackage?
[17:49] <superm1> RainCT, i was thinking same place that the check for the Maintainer with ubuntu.com in the email addy went
[17:50] <RainCT> that's in dpkg I think
[17:50] <RainCT> but I don't see how your idea would work..
[17:50] <superm1> RainCT, well something along the lines of doing a "lite" checkout
[17:50] <RainCT> (beside the difficulties to determine wheter it's committed or not, for each build ssytem)
[17:51] <superm1> well just checking if its committed to the branch listed in debian/control
[17:51] <RainCT> a) what happens if the Vcs- fields are from Debian? How would you do an Ubuntu revision?
[17:51] <superm1> well there would have to be exceptions for that i suppose.
[17:52] <superm1> or a local branch would have to be made from debian
[17:52] <superm1> which actually wouldn't be a "horrible" idea, but then you're right you run into cases of projects using the bzr branch/git branch differently
[17:53] <RainCT> b) what's if you don't want to commit it? (eg, I'm not going to commit the upload that I'm getting ready now, as it's a checkout from the branch with some stuff removed as I'm not sure if it would need a Freeze Exception)
[17:53] <superm1> well I guess i'll need to get a nice spec together for this then to cover cases like that
[17:53] <RainCT> :)
[17:54] <RainCT> or perhaps just add a warning
[18:27] <RainCT> wow, I think I fixed pbuilder-dist
[18:27] <RainCT> anyone up for desting?
[18:27] <RainCT> *testing
[18:35] <mok0> RainCT: I'd be interested if you would make it use cowbuilder
[18:36] <RainCT> mok0: what's the difference?
[18:36] <mok0> cowbuilder is a lot faster
[18:37] <mok0> RainCT: you don't need the packing/unpacking of base.tgz
[18:37] <RainCT> mok0: oh, cool. is it just pbuilder but without compressing or is there some other difference?
[18:39] <mok0> RainCT: it uses cowdancer, allowing copy-on-write file access
[18:40] <mok0> http://packages.ubuntu.com/hardy/utils/cowdancer
[18:46]  * RainCT will have a look at it some day :)
[18:46] <ScottK2> RainCT: Are you interested in hacking on the pbuilder package itself?
[18:47]  * geser uses pbuilder on a tmpfs and it is really nice and fast :)
[18:47] <ScottK2> geser: I was thinking it'd be nice for pbuilder to have a --build-twice-in-a-row option.
[18:49] <superm1> ScottK2, what for?
[18:51] <ScottK2> In Debian there is a requirement for packages to build twice in a row to make sure the archive is rebuildable.
[18:51] <ScottK2> It does ensure things are clean at the end of the build.
[18:52] <ScottK2> So it's an additional QA check that I suspect would be easy to integrate into pbuilder.  Currently I use pbuilder login and debuild is twice.
[18:52] <geser> ScottK2: couldn't you do it through hooks?
[18:53] <ScottK2> I suspect you could, but part of the point of pbuilder is to make it easy to build in a clean environment.
[18:54] <superm1> ScottK2, ah so that allows for sane circular dependencies if necessary too
[18:54] <superm1> correct?
[18:54] <kdub> looking at either of these would be appreciated: http://revu.tauware.de/details.py?package=tv-grab-dvb and http://revu.tauware.de/details.py?package=ocropus
[18:55] <RainCT> kdub: you know there is Feature Freeze?
[18:55] <ScottK2> superm1: I don't think so.  I think the first build would still fail, but I'm not sure.
[18:56] <kdub> nope im a newb to the whole motu thing
[18:58] <RainCT> kdub: well, I'll look at one, but recently the so called "Feature Freeze" started; this means that no new packages can get into Hardy unless they get a Feature Freeze Exception (ie, two members of the motu-release team accept it)
[18:59] <ScottK2> And for new packages there needs to be a really good reason.
[19:00] <kdub> RainCT: thanks, im just trying to get started, im not hellbent on getting anything into hardy...
[19:01] <ScottK2> kdub: Your best bet for learning now is to look for bugs tagged bitesize and packaging and see if you can work on any of those.
[19:04] <kdub> ScottK2: thanks, i think ill go start that now...
[19:06] <ScottK2> kdub: Another option is to look for bugs tagged patch and see if you can package the patch and produce a good debdiff.
[19:15] <RainCT> kdub: I'm looking at ocropus. First impressions: Remove README.Debian; the syntax to close the bug in debian/changelog is wrong, it should be just "LP: #nnnn"; you probably want priority: optional in debian/rules; short and long descriptions in debian/rules are wrong, check the packaging policy; debian/copyright: "It was downloaded from <url://example.com>", list full names of authors and their email (between <and>, next to the name) if possible;
[19:18] <kdub> RainCT: thanks! tv grab probably needs those fixes too...
[19:33] <RainCT> is it possible to "whitelist" a command so that sudo doesn't ask the password for it?
[19:37] <ScottK> RainCT: I think the answer was even if you could, you really almost certainly don't want to.
[19:40] <RainCT> ScottK: I want :). It's very anoying having to write the password for pbuilder each time, and I often forget to do so as it needs some seconds to ask it. Also, this computer is only used by me (and like 95% of time when I'm away the screen is locked), so the biggest danger is that one that I might write the password somewhere else (like here) insted of on the terminal.
[19:41] <ScottK2> There is always sudo -i then run pbuilder, but no guarantees on the results.
[19:43] <RainCT> Wasn't there some file where you could specify commands that can run as root without password? Or did I dream that? :P
[19:43] <TheMuso> RainCT: There is also sbuild.
[19:44] <TheMuso> Once set up, no root password is necessary.
[19:44] <vorian> jdong: thanks for the heads up :)
[19:44] <jdong> vorian: certainly :)
[19:51] <geser> RainCT: you can whitelist a command (incl. options) in sudoers
[19:59] <ScottK2> norsetto: I'd appreciate it if you'd ack Bug 192535 and Bug 192622
[19:59] <ubotu> Launchpad bug 192535 in usplash-theme-ubuntustudio "FF: General exception for Ubuntustudio packages." [Undecided,New] https://launchpad.net/bugs/192535
[19:59] <ubotu> Launchpad bug 192622 in kdesudo "[Feature Freeze Exception]New upstream release (kde4 port)" [Undecided,New] https://launchpad.net/bugs/192622
[19:59] <ScottK2> norsetto: Bug 192486 too
[19:59] <ubotu> Launchpad bug 192486 in nuvexport "MythTV 0.21 Suite FFe" [Undecided,New] https://launchpad.net/bugs/192486
[20:00] <ScottK2> TheMuso: Or you ^^^
[20:00] <norsetto> scottk2: to tell you the truth I would feel kind of silly to ack tonio/jr
[20:00] <bmhm> hi, I'd like to request an update of "pioneers", so I can play with my friends (they're on windows) again
[20:00] <ScottK2> norsetto: Someone has to do it.
[20:05] <bddebian> Heya gang
[20:07] <ScottK2> Heya bddebian.
[20:07] <bddebian> Hi ScottK2
[20:09] <norsetto> bidibibodibidou bddebian
[20:10] <bddebian> Heh, hi norsetto
[20:10] <hellboy195> norsetto: thx for looking at my stuff :)
[20:11] <norsetto> hellboy195: my pleasure ;-)
[20:24] <ScottK> superm1: Would you mind filing a general FFe bug like Ubuntu Studio did (see Bug #192535) so we can get a MythTV FFe for this cycle documented.
[20:24] <ubotu> Launchpad bug 192535 in usplash-theme-ubuntustudio "FF: General exception for Ubuntustudio packages." [Wishlist,Confirmed] https://launchpad.net/bugs/192535
[20:28] <bmhm> hi, I'd like to request an update of "pioneers", so I can play with my friends (they're on windows) again
[20:30]  * RainCT wonders what ScottK thinks about bmhm's question
[20:30] <bmhm> yeah
[20:31] <bmhm> there are no .deb-packages at all
[20:31] <ScottK> bmhm: No .deb for pioneers at all or none for the updated version?
[20:32] <bmhm> at all
[20:32] <bmhm> hardys packages wont work
[20:33] <ScottK> So there is a Hardy package, but it's incompatible with the current version?
[20:33] <ScottK> bmhm: ?
[20:33] <bmhm> yeah because of libpango and libc6
[20:33] <bmhm> ScottK: I was typing
[20:34] <ScottK> In general, I think that it's reasonable to update networked games for multi-platform compatibility.  If someone were willing to package the newer version, I'd personally be inclined to approved the request.
[20:35] <bmhm> ScottK: I can try, but I never created .deb-packages other than by checkinstall
[20:36] <bmhm> additionaly, I just got amd64-installations
[20:36] <ScottK> That won't get accepted.
[20:36] <ScottK> So the trick would be to find  MOTU that's interested in the game.  Maybe RainCT qualifies?
[20:37] <bmhm> i might want to apply for canonical if my girlfriend is beeing sent to africa. I am an application developer, but just did mainframe-assembler so far ^^
[20:38] <Nafallo> ehrm
[20:38] <Nafallo> what?
[20:38] <bmhm> IBM's z/OS High level Assembler
[20:38] <Nafallo> why would your gf have to be an african? :-P
[20:38] <bmhm> that's what I do at work
[20:38] <bmhm> noooo
[20:38] <norsetto> scottk: might I be so bold as to ask why the beta condition for mythtv?
[20:38] <bmhm> you didn't get it.. she studies theology here in germy, and german protestant churches might send her to africa
[20:38]  * RainCT doesn't know the game but might have a look at this some day this week if he gets subscribed to a bug explaining the issue
[20:38] <bmhm> then I would follow her
[20:38] <ScottK> norsetto: Sure
[20:39] <RainCT> bmhm: Canonical's offices aren't in africa :P
[20:39] <bmhm> damn ^^
[20:39] <Nafallo> I was about to say that :-)
[20:39] <RainCT> afaik they have administration in Isle of Man, servers in London (UK) and support team in Canada, and developers work from their home
[20:40] <bmhm> home? sounds good enough to me
[20:40] <RainCT> also, most MOTU's aren't from Canonical but just volunteers
[20:40] <bmhm> I wouldn't want to be a motu
[20:40] <ScottK> norsetto: Two reasons: 1. The myth packages aren't used just by mythbuntu, so I'm not comfortable with a complete waiver like I am with the meta packages.  2.  To give the mtyhbuntu packagers leverage with upstream to say it must be released by X date or I don't know if it gets in.  That way there's some wiggle room if last minute problems ocurr.
[20:40] <bmhm> I'd apply as a application developer
[20:41] <Nafallo> RainCT: not entirely true, but lets not talk about that now :-)
[20:41] <bmhm> :-)
[20:41] <RainCT> Nafallo: which part?
[20:41] <norsetto> scottk: right, but what if we have a problem by beta? We end up having a semi-completed suite which seems worst than sticking to 0.20?
[20:42] <ScottK> norsetto: We probably waive it through after taking a close look at it, but I think having the free pass expire before release is sensible.
[20:42] <Nafallo> RainCT: dunno how confidential they want to keep things.
[20:43] <Nafallo> RainCT: so can't really tell
[20:43] <norsetto> scottk: just trying to be pragmatic here, I think it makes sense to either grant it or not
[20:43]  * norsetto is not well known for mental flexibility after all
[20:44] <ScottK> norsetto: I can see that, but I'd like to have an end to a free for all on packages that complex (same reason, BTW, why I haven't asked for a general waiver on clamav).
[20:44] <bmhm> RainCT: I am pretty sure hardy's packages would work if you'd just drop dependencies to gutsy's
[20:44] <ScottK> bmhm: So Hardy is up to date, it's a backport to Gutsy you want?
[20:44] <bmhm> yeah
[20:44] <bmhm> exactly
[20:45] <ScottK> That's different.
[20:45] <norsetto> scottk: thats right, and is the same reason why I don't feel very confortable in acking it
[20:45] <bmhm> I installed hardy already on my laptop... some crashes but in general it works flawlessly
[20:45] <ScottK> norsetto: I'm pretty sure we do it this way they'll release before the beta and it's no trouble, but OK if you aren't comfortable.
[20:46] <bmhm> I was about to make some requests for kernel compile options so my battery lasts longer...
[20:46] <ScottK> bmhm: Then what you want is backports and the prevu tool.
[20:46] <ScottK> !backports | bmhm
[20:46] <ubotu> bmhm: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[20:46] <emgent> heya all
[20:47] <bmhm> ScottK: sorry, I now what backports are, but just forgot about them
[20:48] <ScottK> No problem.  I suspect what you are wanting is a source backport since the packaging will have to be changed.
[20:48] <bmhm> source backport? So no binaries are being shipped?
[20:48] <bmhm> just because some motus set false dependencies? I did take a look at pioneer's webpage - deps didn't change at all
[20:49] <bmhm> so why not lower dependencies at all?
[20:49] <bmhm> also, ScottK, the wiki is not up to date. there is no link to gutsy's request page :P
[20:50] <ScottK> bmhm: It may be that the dependencies are a result of what it was compiled against and if you build it against the Gutsy tool chain using prevu it will be just fine.
[20:50] <ScottK> bmhm: It's a wiki.  Feel free to fix it.
[20:50] <bmhm> ah i see
[20:50] <bmhm> ScottK: I don't know the link, so I cannot fix it ;-)
[20:51] <bmhm> I created some pages already
[20:51] <bmhm> erhm... one to be honest. My laptop's page.
[20:51] <ScottK> bmhm: No, a source backport is when the package has to be changed when backported.  Binaries still get built, just it takes a source upload to make the change rather than just a straight copy from the existing Hardy package.
[20:51] <bmhm> ok thanks for the info, ScottK
[20:51] <ScottK> No problem.
[20:52] <bmhm> I will see if I can do that on my own. Can't be that hard, can it?
[20:52] <ScottK> I've heard people say prevu is pretty easy, but I've not used it.
[20:53] <bmhm> I just don't know about cross-compiling. But I'll see.
[20:55] <ScottK> RainCT: You might want to look at a message in debian-devel subject MBF: Debian upstream version higher than watch file-reported upstream version - a couple of your packages appear.
[20:56] <RainCT> ScottK: is it a problem?
[20:56] <ScottK> Perhaps.
[20:56] <RainCT> and which are they? afaik it's only one
[20:57] <ScottK>  glest (U) and   lightyears
[20:57] <RainCT> ScottK: glest's watch file is broken; I already fixed it in SVN some hours ago (and it isn't mine, I'm co-maintainer) :)
[20:58] <ScottK> OK.  I'm just reading the message.
[21:00] <RainCT> ScottK: but thanks for the warning :)
[21:00] <emgent> jdstrand, ping
[21:00] <RainCT> btw, CC By-NC is non-free, or?
[21:01] <ScottK> RainCT: NC = Non-commercial, right?
[21:01] <RainCT> yes
[21:03] <ScottK> RainCT: Then it's non-free/multiverse
[21:05] <RainCT> ScottK: thx
[21:05] <RainCT> (ubuntu-dev-tools 0.26 uploaded)
[21:09] <RainCT> hm.. anyone knows it it's easy to get new scripts into cdbs?
[21:12] <RainCT> bah nvm, I would be unable to create one anyways :P
[21:12] <siretart> RainCT: most likely it depends on the scripts
[21:14] <norsetto> shouldn't we use an ubuntu version also for rebuilds!?
[21:14] <bmhm> RainCT: so will it be updated or do I have to register for launchpad or so?
[21:14] <Nafallo> norsetto: buildX
[21:14] <ScottK> norsetto: No.  If it's a no change rebuild, use build1 so it'll get sync'ed over in Hardy +1
[21:15] <bmhm> s/register/sign up/g
[21:15] <norsetto> so if its -1 it becomes -1build1, ok, thanks
[21:16] <ScottK> norsetto: Yes
[21:18] <bmhm> ScottK: : so will it be updated or do I have to sign up for launchpad or so?
[21:18]  * ScottK grumbles about improvments in requestsync...  Spawning an editor is really more trouble than was needed.
[21:18] <ScottK> bmhm: Did you test it?
[21:19] <bmhm> Hardys packages worked well, I used --force for testing purposes
[21:19] <ScottK> bmhm: The backports process starts with someone asking for a backport by filing a bug against gutsy-backports (so yes, you need to sign up on Launchpad).
[21:19] <bmhm> :-(
[21:20] <bmhm> ScottK: OK, I'll see
[21:24] <ScottK> Also you need to build the package against the Gutsy tool chain for the testing to count.  Forcing the Hardy package doesn't cut it.
[21:24] <ScottK> (hence my earlier comments about prevu).
[21:28] <bmhm> ScottK, RainCT: Here you are: https://bugs.launchpad.net/gutsy-backports/+bug/192751
[21:28] <ubotu> Launchpad bug 192751 in gutsy-backports "Backport of network game "pioneers"" [Undecided,New]
[21:29] <bmhm> I hop I did it right
[21:29] <bmhm> *hope
[21:35] <ScottK> bmhm: That's a proper request.  To get approved/done it needs someone to build/test it.
[21:37] <bmhm> fine
[21:37] <bmhm> thanks for helping
[21:39] <RainCT> What name do you suggest for the package that will contain Python modules (from ubuntu-dev-tools source package; that is, right now, the new ppaput module)? python-ubuntu-devtools?
[21:41] <TheMuso> RainCT: Why add --no-changelog for update-maintainer?
[21:42] <RainCT> TheMuso: because I can't never remember if it is --nochangelog (which was the only accepted option before) or --no-changelog.
[21:42] <pochu> RainCT: -n ? :)
[21:42] <TheMuso> RainCT: Ok, fair enough, but it seems rather pointless IMO.
[21:43] <RainCT> :P
[21:43] <TheMuso> RainCT: You didn't document it in the usage either.
[21:44] <RainCT> TheMuso: listing both was to long :P
[21:44] <RainCT> (in the --help, dunno, why I didn't list it in the manpage; adding it there)
[21:46] <RainCT> s/dunno,/dunno
[21:48] <RainCT> TheMuso: any suggestion for the python-* package naming?
[21:48] <TheMuso> RainCT: Nope.
[21:49] <norsetto> RainCT: you could have added it as a --oh-god-I-forgot-it-again option (fairly easy to remember too)
[21:50] <norsetto> this is a good candidate for the most unpronounceable package name: sabnzbdplus
[21:51]  * RainCT names it python-ubuntu-utils for now
[21:51] <RainCT> norsetto: heh
[21:52]  * RainCT votes for it
[21:57] <ScottK> RainCT: Why are you making a separate package?
[21:58] <RainCT> ScottK: Andrew Hunter split ppaput into a module and the command per see, which should get into a python- package (dholbach is happy with this)
[21:58] <RainCT> (er, the module should get into a python- package, not the command)
[21:59] <ScottK> So you can make a 2nd binary pakcage out of the current source package.  Since it's a python module, Pyhon policy tells you what the binary package name should be.
[22:01] <RainCT> ScottK: the idea is to later add more modules to this package (if policy allows this)
[22:01] <ScottK> Right.
[22:02] <ScottK> Source package name can be whatever you want (I recommend leaving it in the ubuntu-dev-tools source package)
[22:02] <bmhm> hmm I will try prevu now
[22:02] <bmhm> perhaps I can contribute, too. Or at least help.
[22:03] <ScottK> bmhm: Great.
[22:03] <bmhm> german wiki at ubuntuusers is pretty good
[22:04] <bmhm> hmm I should request a package "prevu-doc" =)
[22:04] <bmhm> no man-pages, no --help...
[22:04] <ScottK> bmhm: Feel free to pick on jdong.  It's his baby.
[22:04] <bmhm> :D it's ok
[22:05] <bmhm> enough trouble for today ;-)
[22:05] <RainCT> jdong: add a manpage, I like them ;)
[22:05] <bmhm> xD
[22:06] <bmhm> I am off, gn8
[22:07]  * norsetto remembers telling jdong about manpages about 6 months ago ....
[22:08] <RainCT> jdong: have a look at POD if you don't like groff :P
[22:08]  * norsetto wonders who is the scotty in bmhm's last comment and why he did that ....
[22:08] <TheMuso> RainCT: I like manpages also.
[22:09] <TheMuso> I think in general, people find manpages tedious to write.
[22:09] <hellboy195> TheMuso: normal users don't use manpages ;)
[22:09] <jdong> norsetto: yeah yeah yeah manpages, on my todo list :)
[22:10] <RainCT> jdong: do you know POD? I'd write a post about it, but the last Wordpress upgrade broke my block :P
[22:10] <TheMuso> hellboy195: I know, but technical users do.
[22:10] <jdong> I was gonna write it earlier but when I got started writing it, I thought about doing some UI changes :)
[22:10] <jdong> RainCT: heard of it, yeah. I personally have no problem using groff just need to find the time to do it
[22:10] <hellboy195> TheMuso: there aren't a lot out there ^^
[22:11]  * RainCT just needed to say that wordpress is evil :D
[22:11] <TheMuso> hellboy195: In any case, its policy that we write them.
[22:11] <hellboy195> TheMuso: yeah, sure
[22:11]  * RainCT announces that he won't advocate any package without manpage :P
[22:12] <jdong> prevu was packaged way in the historical times
[22:12]  * ScottK remembers someone grumbling just yesterday about pyclamd man pages ...
[22:13] <RainCT> *any package cointaining executable commands without manpage ;)
[22:27] <protonchris> can anyone point me to an example get-orig-source that uses uscan/uupdate?
[22:35] <persia> protonchris: http://lists.debian.org/debian-devel-games/2008/02/msg00135.html is a recent example of one of mine.
[22:40] <pochu> hey persia. I had forgot about the gstreamer plugin. I have some time now, do you want to explain me what it is about?
[22:42] <persia> pochu: I'm a little time-limited, but I noticed your name in a bunch of changelogs, so wanted to ask for your help.  I was trying to include the wildimidi gstreamer plugin to address bug #111555, but kept getting stuck because the plugin was unable to initialise.
[22:42] <ubotu> Launchpad bug 111555 in timidity "package gstreamer sw midi playback plugin" [Low,Confirmed] https://launchpad.net/bugs/111555
[22:43] <persia> I added libwildmidi0-dev to build-depends, patched the makefile to build wildmidi without timidity, and included it in the .install file.  Am I missing some essential piece to make it work?
[22:43] <protonchris> persia: thanks.
[22:44] <RainCT> good night
[22:45]  * norsetto thinks he is going to bed
[22:45] <pochu> persia: not that I know of
[22:45] <persia> protonchris: There's a couple bugs in that code, e.g. it should generate $(package)_$(version).orig.tar.gz rather than $(package)-$(version).orig.tar.gz, and it doesn't check to make sure the temporary directory doesn't exist before repacking.
[22:48] <persia> pochu: Hmm.  My problem was that gst-inspect had trouble loading it, but perhaps I'll have to dig through the symbols.  Thanks.
[22:48] <pochu> persia: what's the problem with b-d on a daemon?
[22:48] <persia> pochu: Because the daemon can't launch in the buildds (plus, it's messy).
[22:49] <pochu> persia: slomo is the gstreamer mister. I'm just learning, btw :)
[22:49] <pochu> s/mister/master/
[22:51]  * norsetto IS going to bed
[22:51] <norsetto> see you all
[22:52] <hellboy195> gn8 @all
[23:33] <pochu> persia: I don't understand what the daemon issue is. Does libtimidity ship a daemon? And what's the conflict issue? There's no libtimidity in the archive...
[23:36] <DktrKranz> does anybody know where I can get a copy of multidistrotools?
[23:38] <DktrKranz> nevermind, found
[23:38] <persia> pochu: libtimidity is a different source than timidity, and is an overlay library.  Gstreamer is written against timidity directly.  Earlier discussion on the issue (resulting in your comment on the bug) was about extracting a hypothetical libtimidity out of timidity, but I now believe this would be a confusing solution because of the different existing upstream libtimidity, and further find that the timidity package doesn't really have an extrac
[23:41] <pochu> persia: your message was cut, "package doesn't really have an extrac"
[23:41] <persia> an extractable library, as such, and would likely need a serious rewrite to expose an embedded library.  (Also, I'm not really here now)
[23:42] <persia> (and really not here now... )