[00:25] <nxvl> jcastro: ping
[00:36] <cyberix> Are Mondays still REVU days?
[00:41] <persia> cyberix: Wednesdays were announced as REVU days, but there hasn't been a lot of activity.
[02:00] <leleobhz> how can i see if a package have a mantainer into ubuntu?
[02:02] <RAOF> leleobhz: Generally, we don't have the same maintainer concept as Debian.  You can check the changelog to see if someone has consistently been uploading, though.
[02:02] <leleobhz> RAOF: https://launchpad.net/ubuntu/+source/praat
[02:02] <leleobhz> well, have a lot of versions patched by Auto-sync
[02:03] <leleobhz> RAOF: and so, i mantain a unnoficial package on my repositories
[02:03] <leleobhz> its to ask too how can i be a package mantainer
[02:03] <RAOF> Ok.  So that means we've just been taking it straight from Debian, and it'll have a Debian maintainer.
[02:04] <leleobhz> RAOF: ?
[02:04] <RAOF> It looks fairly active in Debian, too.  You probably want to talk with the Debian maintainer if you're interested in that package.
[02:04] <leleobhz> RAOF: im interested only in ubuntu, not in debian
[02:04] <leleobhz> mainly beucause i dont want to be a dd
[02:05] <leleobhz> but a ubuntu member
[02:05] <RAOF> leleobhz: https://wiki.ubuntu.com/MOTU is the canonical page.  But to start off with you can file and fix bugs that you're interested in.
[02:05] <leleobhz> RAOF: my problem is im very good with shell and some python
[02:05] <slangasek> It's Ubuntu's preference to not diverge from Debian on individual packages where this is feasible; that means that talking to the Debian maintainer is still the best first step
[02:06] <RAOF> Heh.  I don't much want to be a DD either, but I maintain a couple of Debian packages.  You then get Ubuntu (and a bunch of other derived distro) packages for free.
[02:06] <leleobhz> RAOF: a.k.a. im not so good to patch complex bugs...
[02:06] <RAOF> leleobhz: Then patch simple bugs :)
[02:07] <leleobhz> RAOF: ;]
[02:07] <RAOF> Heh, nice typo in that changelog.
[02:07] <leleobhz> the main problem of praat is the updates it have...
[02:07] <leleobhz> its at least 3 new version every month
[02:07] <leleobhz> its a reason ive created a fork of this package for ubuntu.
[02:08] <leleobhz> RAOF: http://www.fon.hum.uva.nl/praat/manual/What_s_new_.html
[02:09] <RAOF> It looks like the Debian maintainer's keeping up with the releases, though.
[02:09] <slangasek> why is the frequency of rleeases a "problem"?
[02:09] <slangasek> s/rleeases/releases/, too
[02:10] <leleobhz> RAOF: what take my attention is Auto-Sync... that i dont know what is
[02:10] <RAOF> leleobhz: That's the process by which we automatically take new/updated packages from Debian Sid and copy the source to Intrepid.
[02:11] <leleobhz> slangasek: err... may the frequency of bugfixes? its a very buggy program...
[02:11] <leleobhz> RAOF: hmmmm, and for final releases?
[02:11] <RAOF> Ubuntu is based on Debian, and most of our packages are copied unchanged from Debian.  And the vast majority of the rest are trying to make it so we can copy them unchanged from debian :)
[02:11] <leleobhz> get the lattest sid at freeze date?
[02:11] <RAOF> Yup.  And later, but manually, if the Sid package has important fixes.
[02:11] <slangasek> leleobhz: so you're saying that frequent bug fixes are... bad?
[02:12] <slangasek> leleobhz: as RAOF mentioned, the Debian maintainer is keeping up with the upstream releases; so I don't understand what the problem is, here
[02:13] <leleobhz> slangasek: no... (sorry by bad english) im saying praat is a buggy software... and have a lot of bugfixes lauched every month
[02:13] <RAOF> If the problem is that the new releases aren't making it into Hardy, then that's entirely expected.  Hardy's released, and hence doesn't get new versions of stuff (without fairly significant paperwork).
[02:13] <leleobhz> anyway, ive understood the debian sincronism
[02:15] <leleobhz> RAOF: can be changed the releasing process?
[02:15] <RAOF> No
[02:15] <leleobhz> like: stay in hardy 5.0.X
[02:15] <leleobhz> and all X be updates?
[02:15] <RAOF> If it's so buggy that it's useless, then it shouldn't be in the archives.
[02:16] <leleobhz> heh... isnt program fault.. its very userfull, but almost release have a bugfix..
[02:16] <RAOF> That's the way with all software.
[02:17] <RAOF> There's _always_ bugfixes in new releases.  And almost always new bugs introduced.  That's why the default upgrade policy is "no" - at least that way, you're stuck with the bugs you know!
[02:17] <leleobhz> hmmm.... ok...
[02:18] <leleobhz> another: have some policy beyond updates on ppa?
[02:18] <RAOF> There are ways to request exceptions to the default policy, but they generally want the minimum possible change to fix a bug.
[02:18] <RAOF> PPA's aren't official.  You can do what you want with them.
[02:19] <leleobhz> RAOF: how can i see packaging related bugs?
[02:19] <leleobhz> (i think this is a thing i can handle)
[02:19] <jcastro> search launchpad for "bitesize" bugs, those are a great way to get started
[02:20] <slangasek> jcastro: it seems he's interested in a particular package, which only has two open bugs in LP :)
[02:20] <slangasek> (both of them segfaults, whoo)
[02:20] <jcastro> yeah but he can practice fixing others. :p
[02:20] <slangasek> :-)
[02:21] <jcastro> actually I am losing in Scrabble and only half following the conversation
[02:21] <leleobhz> slangasek: well, this package is a little problem to me (no more since my unofficial packageS)
[02:21] <nxvl> jcastro: have you tried plukr? is like better than friendfeed IMHO
[02:21] <leleobhz> slangasek: but anyway i want to start helping with something
[02:21] <jcastro> nxvl: ugh, not another one
[02:21] <slangasek> leleobhz: oh, then jcastro's suggestion is a good one :)
[02:22] <nxvl> jcastro: there are A LOT!
[02:23] <nxvl> jcastro: http://www.plurk.com/
[02:25] <leleobhz> slangasek: have some pre-requisite to fix bugs except be in lauchpad?
[02:26] <slangasek> leleobhz: there are no prerequisites for solving bugs; there are processes for getting bugfixes uploaded to Ubuntu that you would have to follow once you know a fix
[02:26] <slangasek> I believe the MOTU wiki link posted earlier will help explain this
[02:36] <leleobhz> slangasek: stupid ask, why lintian tell-me hardy is a invalid target distribution?
[02:36] <leleobhz> (mind note: im using hardy)
[02:36] <ryanakca> How could one build knmap on a host without internet access? The manpage is in docbook format and http://paste.debian.net/5585/
[02:37] <leleobhz> E: praat_5.0.24-1_source.changes: bad-distribution-in-changes-file hardy
[10:38] <Serega> hi all
[12:58] <Polo> hi, I put some packages on revu, and I can see on the lintian file, "source: out-of-date-standards-version 3.7.2 (current is 3.7.3)"
[12:58] <Polo> what should I do ?
[12:59] <RainCT> Polo: change the Standards-Version in debian/control to 3.7.3
[13:00] <Polo> ok thanks
[13:13] <persia> Erm.  Shouldn't we be looking at standards-version 3.8.0 now?
[13:13] <Iulian> Hey
[13:26] <sistpoty> hi folks
[13:26] <TheMuso> persia: I'd say once lintian and the actual policy itself ihit intrepid we could...
[13:29] <sistpoty> persia: has the timeframe for motu-sru extension already passed? (I'm sure about the 48h bit, but not about the "or so" *g*)
[13:29] <sistpoty> persia: if so, can you finally add the new members? *g*
[13:32] <persia> TheMuso: I'd probably accept either policy on REVU now, but I agree with you for NEW, and it might make sense to combine them.
[13:32] <persia> sistpoty: It's the or so bit.  I had vaguely planned to do it tonight, but might have done it in the morning if I wasn't prompted.
[13:33] <sistpoty> persia: thanks!
[13:51] <sistpoty> persia | TheMuso: can you add me to ubuntu-universe-sponsors? I just feel like clearing the queue a little bit, and otherwise I can't unsubscribe u-u-s
[13:56] <persia> sistpoty: ~sistpoty?
[13:56] <sistpoty> persia: yep
[13:56] <persia> sistpoty: Done, and done.
[13:56] <sistpoty> persia: thanks!
[13:57] <persia> sistpoty: Much as I appreciate the accolades, you get a free 30-minute cache for that.  No need to repeat so often :)
[14:06] <sistpoty> heh
[14:18] <ryanakca> How could one build knmap on a host without internet access? The manpage is in docbook format and http://paste.debian.net/5585/
[14:19] <persia> ryanakca: Depend on something that provides the DTD
[14:19] <persia> s/Depend/Build-Depend
[14:19] <ryanakca> persia: ah, ok, and then change the DTD in knmap.1.docbook to /usr/share/foo/bar.dtd ?
[14:20] <persia> ryanakca: I think there's some mangling done internally, if you have the right one, but that ought work too.  I haven't looked at docbook in a long time, and am fuzzy on the details.
[14:21] <ryanakca> persia: thanks
[15:17] <albert23> sistpoty:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478524 may give an answer to your soyuz question
[15:18] <sistpoty> thanks albert23, /me looks
[15:19] <albert23> sistpoty: and hs-plugins builds fine if you drop build-indep-stamp from the build: target
[15:20] <sistpoty> albert23: hm. but that would not build the indep part on i386 then
[15:21] <albert23> sistpoty: the indep part will be build via binary-indep --> install-indep --. build-indep-stamp
[15:22] <sistpoty> albert23: but I can't see how the indep thingy is called from build-arch atm. can you?
[15:23] <sistpoty> (so I don't think that bug report applies here)
[15:23] <albert23> sistpoty: on i386, the buildd will call dpkg-buildpackage -b which will call debian/rules binary
[15:23] <albert23> yhen binary depends on binary-indep
[15:24] <sistpoty> albert23: yes, but for binary, build-depends-indep must be installed according to policy.
[15:24] <albert23> sistpoty: on i386 the buildd will install b-d-i
[15:25] <sistpoty> albert23: yes, and there it builds fine. that's why I linked to the amd64 FTBFS log ;)
[15:25] <albert23> sistpoty: so on amd64 the buildd does not install b-d-i and calls dpkg-buildpackage -B
[15:26] <albert23> the dpkg-buildpackage calls debian/rules build, which causes the problems
[15:26] <albert23> for the build target b-d-i should be installed as well
[15:27] <sistpoty> albert23: ah, so it's a bug in dpkg-buildpackage? (where did you see the -B btw., as I can't see that in from the log)
[15:27] <albert23> so either the buildd must install b-d-i before calling dpkg-buildpackage -B
[15:27] <albert23> or dpkg-buildpackage -B should not call debian/rules build
[15:27] <albert23> that's the discussion in the debian bug
[15:28] <sistpoty> ah. I guess I should have read the bug to the end *g*
[15:28] <albert23> sistpoty: I don't see the -B either, just the effect of either binary or binary-arch being called
[15:44] <sistpoty> bug filed: 238141
[16:07]  * sistpoty is off again... cya
[18:03] <devfil> ut is possibile to sync packages from experimental?
[18:03] <crimsun> yes
[18:03] <geser> yes
[18:04] <devfil> packages not in ubuntu
[18:05] <crimsun> (yes)
[18:06] <devfil> crimsun: so I simply request a sync for example for http://packages.debian.org/sid/gstreamer0.10-plugins-farsight package, is this right?
[18:10] <crimsun> devfil: have you confirmed that you can drop the gstreamer-tools build-dependency?
[18:10] <devfil> crimsun: I'm trying, it's only an example
[18:11] <crimsun> it seems like it still requires the Ubuntu delta
[18:11] <crimsun> e.g., dh_gstscancodecs
[18:13] <devfil> crimsun: yes, I posted the first package I've found
[18:32] <colo939> Hi, I am considering the possibility of developing a GUI front end for ftp as a project for my user interface design class but I am not sure where to start.  I apologize if this is the wrong place for such a discussion
[18:33] <ScottK-laptop> colo939: Why not do something that isn't redundant to a bunch of existing projects?
[18:34]  * ScottK-laptop complains and runs off.
[21:24] <emgent> heya
[21:30] <ryanakca> woah, wicked netsplits :)
[21:32] <\sh> ryanakca: someone is fcking around with the links....wasting traffic that is ;)
[23:04] <txwikinger> When do we go to Standards Version 3.8.0?
[23:30] <sebner> gn8 folks