[00:38] <arand> What is it that keeps changelogs lagging so much in publication? Why would they be anything but simultaneous to package publication?
[01:16] <Darxus> Heh, there's a needs-packaging bug for launchpad.
[02:47] <Darxus> Depends: autopano-sift-c | autopano-sift
[02:47] <Darxus> ^ That'll install autopano-sift-c if it's available, and only autopano-sift if autopano-sift-c isn't available, right?
[02:50] <jbernard_> Darxus: correct, it also allows another package to /provide/ autopano-sift and satisfy the depend
[02:53] <Darxus> jbernard_: Thanks.
[02:54] <Darxus> autopano-sift-c hasn't been packaged, but there's a bug open for that, and I'm just trying to eliminate the need for repackaging.
[02:54] <Darxus> (hugin 2009.2.0).
[02:54] <Darxus> Actually... it would be good if the hugin 0.8.0 package did that too :/
[02:54] <Darxus> Nah, that doesn't matter.
[02:58] <Darxus> Er, kernel packages don't have "kernel" in the package name anymore?
[03:00] <Darxus> Ah, "linux-image".  Weird.
[03:02] <quidnunc> Anyone know where I can find where a python package would specify that it requires version 2.5? I can't find any reference to it in control, just ${python:Versions}
[03:02] <ari-tczew> dunno
[03:06] <Darxus> Wow, kernel packages don't use quilt.
[03:06] <JanC> Darxus: on Ubuntu kernel=linux might be true, but e.g. on Debian it might be "hurd" or "kfreebsd" too I think  ;)
[03:07] <Darxus> JanC: Yes, I agree it's important to have "linux" in the package name, but I don't see that as a reason not to have "kernel" in the package name.
[03:08] <Darxus> Although shortening the package names after putting the more useful "image" vs "headers" in there makes sense.
[03:08] <JanC> I guess some kernel package names are too long already...
[03:11] <Darxus> - NAME = Man-Eating Seals of Antiquity
[03:11] <Darxus> ^ Ubuntu kernel package.
[03:13] <Darxus> Wow, I just realized the kernel packages are fully synked from debian, no patching.
[03:15] <Darxus> Okay, so I'm patching debian version 2.6.31-11.38 with bfs303, so does that make the version 2.6.31-11.38-bfs303-1ubuntu1 ?
[03:24] <Darxus> Or just 2.6.31-11.38-bfs303 ?
[03:28] <ari-tczew> Darxus: want you get patched kernel into ubuntu repos?
[03:29] <Darxus> ari-tczew: Eventually.
[03:29] <ari-tczew> I guess it's impossible :)
[03:29] <Darxus> ?
[03:29] <ari-tczew> eventually, you can send patched kernel on your ppa
[03:30] <Darxus> Yeah, I want to build it and boot it first, since somebody else mentioned they managed to build it but it wouldn't boot.
[03:31] <ari-tczew> yhym
[03:31] <ari-tczew> or other way you can open bug for request apply patch (bfs303?)
[03:32] <ari-tczew> btw. what about hugin? I saw that you're working on merge from experimental (?)
[03:32] <Darxus> The bug is open, bug #424927
[03:33] <Darxus> ari-tczew: Yeah, looks like hugin 0.8.0 got accepted.  I merged hugin 2009.2.0 from debian experimental.  It's done.  But it won't get acked until I find out why the debian maintainer had it in experimental instead of unstable.
[03:34] <ari-tczew> 0.8.0 needs sponsor
[03:34] <ari-tczew> like a libpano
[03:34] <Darxus> Hmm, I thought that would've been taken care of by now :/
[03:35] <ari-tczew> not yet
[03:36] <ari-tczew> if it's have been taken care, status should be a "Fix released"
[03:36] <Darxus> Ah, right.
[03:37] <Darxus> *Wow*, the debian diff against the linux kernel .orig is 295,602 lines.
[03:38] <Darxus> Ah, this is ubuntu specific.  Weird that ubuntu isn't in the version number.
[03:40] <ScottK> Normally for stuff that we know didn't and won't come from Debian we don't bother with Ubuntu in the version number.
[03:41] <ScottK> Ubuntu doesn't use the Debian kernel, but packages it's own, so the ubuntu would be pointless.
[03:44] <ari-tczew> ScottK: could you upload libpano to universe?
[03:45] <Darxus> ScottK: Ah, cool, thanks.
[03:45] <ScottK> ari-tczew: Perhaps later.  What bug?
[03:46] <ari-tczew> bug 440177
[03:49] <ari-tczew> ScottK: maybe you know, ubuntu now longer support epiphany-browser (gecko)? only -webkit?
[03:49] <ScottK> ari-tczew: I don't.  I'm a Kubuntu user
[03:50] <ari-tczew> OK
[03:51] <ScottK> ari-tczew: I just checked an epiphany-browser is in Universe for Karmic, so that is correct.  Firefox is, of course, still supported, so there's at least one Gecko browser supported.
[03:52] <Darxus> Kernel compiles should display an eta.  Or at least percentage complete.
[03:53] <ari-tczew> -gecko is out-of-dated. webkit is 2.28
[04:07] <micahg> I found a dependency was not incremented properly in debian so now ubuntu doesn't knwo the correct version for a package
[04:07] <micahg> what to do?
[04:10] <micahg> ScottK: are you around?
[04:11] <ScottK> micahg: I am.  What's up?
[04:12] <micahg> It seems like kvpnc is FTBFS becuase the dependency on pkg-kde-tools was not bumped to 0.5.0 minimum
[04:12] <micahg> we have 0.4.11
[04:13] <micahg> latest is 0.5.1
[04:15] <micahg> sorry, I'm on an overlapping wireless channel at the moment
[04:15] <micahg> ScottK: any idea what I should do?
[04:17] <ScottK> micahg: I'm not sure why that would cause an FTBFS?  In Karmic it will just use the version present and that's new enough.
[04:17] <micahg> ScottK: no, the failure is because a needed file was added in 0.5.0
[04:18] <micahg> or at least the build thinks it needs it
[04:18] <micahg> I cannot ascertain if it's actually necessary
[04:18] <micahg> http://launchpadlibrarian.net/33004646/buildlog_ubuntu-karmic-i386.kvpnc_0.9.3-1_FAILEDTOBUILD.txt.gz
[04:18] <ScottK> It's a valid packaging bug in any case
[04:19] <micahg> so should I file a sync request against pkg-kde-tools?
[04:19] <ScottK> micahg: I see what you mean.
[04:20] <ScottK> I thought we had 0.5 something
[04:21] <micahg> ok, hopefully that fixes my wireless issue
[04:21] <micahg> ScottK: what did I miss?
[04:22] <ScottK> micahg:What's the last thing you saw from me?
[04:22] <micahg> (10:18:26 PM) ScottK: It's a valid packaging bug in any case
[04:23] <ScottK> micahg: OK.  I also said that I'd thought we had 0.5 something and I see we don't.
[04:24] <micahg> ok, well that seems to be the issue
[04:24] <ScottK> micahg: This close to release, I don't think we want to do a major pgk-kde-tools upgrade.  Perhaps you can pull the missing stuff from 0.5, include it in your debian dir and modify debian/rules to look there.
[04:24] <ScottK> Before there was a pkg-kde-tools all their stuff was kept in the debian dir, so in theory I know that can work.
[04:25] <micahg> this is ridiculous, I apologize
[04:27] <ScottK> Oh?
[04:27] <micahg> my wireless droppiong like this
[04:27] <micahg> so, what should I do?
[04:28] <ScottK> [23:24:19] <ScottK> micahg: This close to release, I don't think we want to do a major pgk-kde-tools upgrade.  Perhaps you can pull the missing stuff from 0.5, include it in your debian dir and modify debian/rules to look there.
[04:28] <ScottK> [23:24:46] <ScottK> Before there was a pkg-kde-tools all their stuff was kept in the debian dir, so in theory I know that can work.
[04:28] <ScottK> micahg: Get it that time?
[04:28] <micahg> yes
[04:28] <micahg> it's a perl module that's missing
[04:28] <micahg> so, I should include that in the kvpnc package?
[04:29] <ScottK> micahg: I'd try that first
[04:29] <micahg> hmm, I've never done this before, but I'll give it a shot, might take me a day or two
[04:30] <ScottK> OK
[04:32] <Darxus> Achieving what I believe is a good clean merge from debian is an exciting first for me, as simple as it was.  Two lines.
[04:43] <micahg> nevermind, I should probably just use it and not install it
[05:20] <ScottK> Darxus: Doing a lot is easy.  Being minimally invasive is a challenge.
[05:21] <Darxus> Heh.
[05:23] <fabrice_sp_> ScottK, do you think you will have time to upload Bug #440177?
[05:24] <fabrice_sp_> just to know if I retain hugin 0.8.0 upload until it's uploaded or not
[05:26] <ScottK> fabrice_sp_: I'm looking at it now.
[05:26] <fabrice_sp_> cool. thanks :-)
[05:26] <ScottK> I thought you uploaded hugin already?
[05:31] <ScottK> fabrice_sp_: It's building now.  It ought to be in the archive to build against in ~75 minutes on the fast archs.
[05:32] <fabrice_sp_> ScottK, I just wanted to build it locally, just to be sure it builds fine, and run fine
[05:32] <ScottK> OK.
[05:32] <fabrice_sp_> will test it today then :-) Thanks!
[05:32] <fabrice_sp_> (again :-) )
[05:33] <ScottK> OK.
[05:56] <micahg> ScottK: ok, I think I got it
[05:56] <micahg> test build in my ppa in an hour hopefully
[06:22] <fabrice_sp_> hyperair, do you really needs sponsoring for bug #442328? :-D
[06:22] <hyperair> fabrice_sp_: sure i do. from an archive admin, that is =)
[06:22] <hyperair> i've got motu-release ACKs and uus ACK from directhex
[06:30] <fabrice_sp_> uus? ahh: I thought you were a MOTU :-/
[06:31] <fabrice_sp_> my bad :-)
[06:32] <fabrice_sp_> I've just subscribed archive-admin
[07:10] <dholbach> good morning
[07:13] <fabrice_sp_> good morning dholbach !
[07:14] <dholbach> hola fabrice_sp_
[07:14] <mase_wk> hey guys i have a kernel packaging question, is this the appropriate place to ask ?
[07:14] <dholbach> #ubuntu-kernel will probably give you better answers :)
[07:15] <mase_wk> dholbach: hmm I've asked numerous times in the channel and the mailing list for the ubuntu-kernel and everyone ignores it so I assumed it was the incorrect place to ask. Will try agin. Thanks
[07:16] <dholbach> they might be sleeping now
[07:18] <swoody> porthose, ping
[07:18] <porthose> swoody, pong
[07:18] <swoody> porthose, just got your email
[07:18] <mase_wk> dholbach: since this is for business use , do you know if there a canonical support option where I would be able to ask packaging questions ?
[07:19] <porthose> swoody, is emgent still mentoring you?
[07:19] <swoody> porthose, I haven't been under MOTU mentoring, for quite a long time. Last I remember something was going on with my original mentor (Pablo I believe?) I don't know what happened, but everything just kind of fell apart from there
[07:20] <swoody> I don't remember anyone by the name of emgent, though
[07:20] <dholbach> mase_wk: can you drop me an email about it - I can make sure your query reaches the right hands - atm I don't know
[07:20] <dholbach> mase_wk: dholbach at ubuntu dot com
[07:20] <swoody> so short answer, no I'm not a mentee, but I would still be interested in becoming a MOTU, still.
[07:21] <mase_wk> dholbach: ok thanks.
[07:35] <micahg1> ScottK: you wouldn't happen to still be up, would you?
[08:23] <logari81> I am looking for documentation on:
[08:23] <logari81> /usr/share/python-support/python-foo.public
[08:23] <logari81> I think it is something new in the last version of dh_pysupport
[08:23] <logari81> is it right?
[08:26] <POX> logari81: /usr/share/doc/python-support/README.gz (what's not there, you should not touch)
[10:14] <surfzoid> Hi, i have finally build deb successfully, now i add this source in synaptic source in ubuntu ? http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu/xUbuntu_9.04/
[10:14] <surfzoid> ** how
[10:15] <directhex> surfzoid, deb http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu/xUbuntu_9.04/ ./
[10:15] <directhex> surfzoid, i think
[10:16] <surfzoid> ha yes i dont think about ./, the proble was amd64-binary :-)
[10:16] <directhex> jms@osc-franzibald:~/Desktop/mitter-0.4.5$ apt-cache policy monoosc | grep Candidate
[10:16] <directhex>   Candidate: 1.0.2.0
[10:16] <directhex> seems to work
[10:17] <surfzoid> directhex: work like a charm :-)
[10:24] <surfzoid> directhex: again :-), the repository is added without error, but i don't see my soft in synaptic
[10:25] <directhex> surfzoid, synaptic's always been a bit funny for me. can't make any suggestions
[10:27] <Laney> did you reload the index? (I think that's synaptic terminology)
[10:29] <surfzoid> i used the refresh cache/aviabe pkg function
[10:29] <surfzoid> hum, the update tool see some pkg of my repo !!
[10:34] <surfzoid> seem to be an author problem, pkg are not authentified !! what can i do ?
[10:57] <surfzoid> directhex: I'm confuse, my deb are now build, but when i install MonoOSC it don't install SyntaxHighlighting, after, the SyntaxHighlighting.dll and MonoOBSFramework.dll are not register in the gac, if i look at the mono build deb file, it have only the dsc one, and it work ....
[10:57] <surfzoid> how i register the dll in the gac and how the dep list is made !!
[10:58] <directhex> surfzoid, there's a helper script in the cli-common-dev package, which you should build-depend on, to insert GAC-related things into a package's postinst
[10:58] <directhex> surfzoid, adding dh_installcligac to the "install" rule in debian/rules will install any assemblies listed in debian/packagename.installcligac into the GAC when the package is installed
[11:00] <surfzoid> build-depend is not only the build requiere but also the requiere ?
[11:01] <j_20091> hello all
[11:01] <j_20091> i am looking for an mentor
[11:02] <directhex> surfzoid, Build-Depends are listed in debian/control as the packages which the compilation machine needs to install in order to compile the packages. as opposed to Depends, which specify things which should be installed automatically for the binary package to work for the end user
[11:02] <surfzoid> oki
[11:03] <directhex> surfzoid, usually for mono packages you can autogenerate the binary dependencies using "dh_clideps" in the "binary" rule in debian/rules, which will expand ${cli:Depends} in debian/control with auto-detected dependencies
[11:24] <directhex> maco, you even got a personal mention from Mikee! lucky you! ¬_¬
[11:25] <directhex> he can't spell though
[13:10] <ari-tczew> hello, I'm looking sponsor for universe to 2 bugs
[13:17] <porthose>  ari-tczew https://wiki.ubuntu.com/SponsorshipProcess
[13:31]  * mok0 just upgraded his workstation to karmic. That was a harrowing experience
[14:21] <MaikB78> Hello
[14:22] <MaikB78>  Am I correct that debian packages build from svn trunk's are meant to define the get-orig-source rule to checkout(actually export) and tar.gz the trunk?
[14:22] <ScottK> Yes
[14:22] <MaikB78> ok
[14:22] <MaikB78> but how to do it with cdbs?
[14:23] <MaikB78> I came across this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494141
[14:23] <MaikB78> which gives me the impression cdbs doesn't work with the get-orig-source hook
[14:24] <joaopinto> MaikB78, it does, just not as expected, from any dir
[14:25] <MaikB78> joaopinto: I fear I didn't get what exactly you mean.  Are there examples around?
[14:26] <MaikB78> I did this stuff a lot in gentoo and arch.  I'd love to get it work on ubuntu/debian
[14:27] <MaikB78> by example I mean:  Which if the *~svn1234 packages are using cdbs?
[14:28] <bdrung_> doko: do you have eclipse already uploaded?
[14:28] <joaopinto> MaikB78, read the bug details, you can have a get-orig-source with cdbs however it will not work when invoked out of the source tree
[14:28] <doko> bdrung_: yes, but we can still update
[14:29] <bdrung_> doko: did you grab it from the git repo or from the ppa?
[14:29] <doko> bdrung_: ppa
[14:29] <MaikB78> joaopinto: will, thx again!
[14:30] <bdrung_> doko: did you adjust the changelog?
[14:30] <doko> bdrung_: what do you mean?
[14:31] <doko> bdrung_: see https://lists.ubuntu.com/archives/karmic-changes/2009-October/010369.html
[14:31] <bdrung_> doko: did you upload it with -0~ppa1?
[14:32] <bdrung_> doko: fyi, i can upload to universe, too
[14:32] <doko> bdrung_: ok, the next uploads are yours!
[14:34] <bdrung_> doko: which value does DEB_HOST_ARCH_CPU have on lpia?
[14:35] <doko> i686
[14:35] <doko> bdrung_: I did attach a patch to my email
[14:36] <bdrung_> doko: yes, saw it. that's why i asked
[14:37] <bdrung_> doko: we have only i386 and amd64 machines and no access to others.
[14:38] <bdrung_> doko: the main discussions are in #debian-java and some are in #eclipse-linux
[14:38] <doko> bdrung_: I know
[14:39] <ScottK> bdrung_: Canonical employees have access to porter boxes in other archs.  sistpoty|work or siretart may be able to arrange MOTU access to Sparc.
[14:42] <sistpoty|work> doko: btw, thanks a lot for working on maven! :)
[14:43] <doko> sistpoty|work: I won't write the FFe's .. so either you find somebody to approve, or we won't make it. also I didn't check yet for other deps of the packages listed
[14:44] <doko> sistpoty|work: so better pester ScottK & co ;)
[14:44] <sistpoty|work> doko: ScottK just gave an ack for the FFe ;)
[14:45] <doko> ScottK: any plans with xz-utils? else I'd like to upload the fix for the data corruption
[14:45] <bdrung_> doko: fix applied, thanks.
[14:47] <ScottK> doko: Please fix that.
[14:48] <ScottK> We looked at updating to beta 9, but it was just to get that fix, so if you can just do the bug fix, that's better.
[14:53] <MaikB78> right now I'm looking at kile's packaging scripts where it seems uscan is used via debian/watch for the svn checkout of the original sources.  Is there a nice wiki page about uscan?
[14:56] <surfzoid> directhex: make: dh_installcligac: Command not found ?
[14:57] <directhex> surfzoid, it's in cli-common-dev
[14:57] <surfzoid> so in to add in dep buil
[14:58] <surfzoid> thanks
[14:58] <MaikB78> I guess this is the right one for uscan: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[15:13] <maco> directhex: yes i know
[15:14] <maco> directhex: on one blog i replied to him "If you can't learn to spell my name, AT LEAST learn to copy and paste it!"
[15:14] <directhex> maco, seems a bit of a knob, tbh
[15:14] <arand> What are the policies for priority of security updates, there was someone who asked why a security update could be priority:low and I became curious about that as well...
[15:15] <maco> directhex: he has a TON of fake names, by the way
[15:15] <maco> directhex: i'm pretty sure you hit a fake one
[15:15] <directhex> maco, he's rather slippery. tor doesn't help.
[15:16] <maco> directhex: PM?
[15:16] <directhex> hm? oh, yes, getting a bit offtopic
[15:16] <jdstrand> arand: are you referring to the 'urgency' field in the changelog?
[15:18] <slacker_nl> yeah, what about that field, it is always "low"
[15:18]  * slacker_nl is curious as well
[15:18] <arand> jdstrand: not perfectly sure to be honest, I would think so.
[15:19] <jdstrand> it means nothing in Ubuntu. it is used in Debian to prioritize builds iirc
[15:19] <slacker_nl> aha
[15:19] <slacker_nl> why doesn't ubuntu use it? Is it not handy to b eable to prioritize builds?
[15:20] <jdstrand> we have a different build system
[15:20] <jdstrand> security builds are given the highest priority
[15:20] <james_w> it's not buildds as such, but testing migration
[15:20] <directhex> urgency is mostly for unstable->testing isn't it?
[15:20] <james_w> and we don't have a "testing" suite
[15:20] <directhex> aha, thought so. HIGH FIVE!
[15:21] <slacker_nl> ahh, k
[15:21] <jdstrand> james_w: interesting-- so that field was introduced when 'testing' first came about?
[15:21] <jdstrand> what was that... wodody?
[15:21] <james_w> I believe so
[15:21] <jdstrand> woody
[15:22] <jdstrand> cool
[15:22] <james_w> it may be used for builds as well, but that's not it's main purpose
[15:22]  * jdstrand learned something new :)
[15:22] <james_w> it is in fact used for build priorities in Ubuntu, but no-one ever sets it
[15:22] <maco> haha
[15:22] <directhex> urgency=OMG
[15:22] <jdstrand> james_w: I was always told it was ignored in Ubuntu. when did this change?
[15:22] <slacker_nl> hehehe
[15:22] <arand> jdstrand: hmm, yea, and it looks like that string is removed in jaunty update manager anyways...
[15:22] <james_w> and you're only talking a matter of hours at the most
[15:23] <james_w> jdstrand: no idea
[15:23] <sistpoty|work> directhex: urgency=EMERGENCY :P
[15:23]  * jdstrand considers letting james_w field this sorts of questions
[15:23] <jdstrand> file:///usr/share/doc/debian-policy/policy.html/ch-controlfields.html#s-f-Urgency
[15:23] <jdstrand> that should've been http...
[15:24] <arand> Yea, launchpad help says it will effect build priority, but by a minuscule bit iirc
[15:24] <jdstrand> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Urgency
[15:24] <jdstrand> and there you go:
[15:24] <jdstrand> 36
[15:24] <jdstrand> Other urgency values are supported with configuration changes in the archive software but are not used in Debian. The urgency affects how quickly a package will be considered for inclusion into the testing distribution and gives an indication of the importance of any fixes included in the upload. Emergency and critical are treated as synonymous.
[15:25] <james_w> we should at least have it so that PPAs with urgency=emergency always score below main archive builds, so that can't DoS Ubuntu
[15:25] <arand> https://help.launchpad.net/Packaging/BuildScores
[15:25] <directhex> james_w, how about urgency=prettyplease where a PPA gets >archive priority due to politeness?
[15:25] <bddebian> Heya gang
[15:25] <arand> low-5 med-10 high-15 emergency-20
[15:26] <sistpoty|work> hi bddebian
[15:26] <bddebian> Heya sistpoty|work
[15:26] <arand> But then the priority has nothing to do with the contents of the package? Only with the build priority?
[15:27] <jdstrand> interesting. I am pretty sure that is new (at least from when I was told)
[15:27]  * jdstrand wonders if one used '-security' in their PPA if the build score would be 6000
[15:29] <bdrung_> doko: we need an updated cdt, too.
[15:29] <arand> james_w: "There are separate build queues for distributions and PPAs." ( https://help.launchpad.net/Packaging/BuildScores ) Does that already solve the DoS problem?
[15:30] <james_w> probabl
[15:30] <doko> bdrung_: yes
[15:30] <jdstrand> arand, james_w: there are official builders for Ubuntu that are separate from PPA builders
[15:30] <bdrung_> doko: is there someone, who maintains it?
[15:30] <jdstrand> it is designed so one can't does Ubuntu via a PPA builders
[15:31] <jdstrand> s/does/DoS/
[15:39] <doko> bdrung_: no, just synced from debian
[15:43] <MaikB78> Am I right that uscan doesn't know how to extract a tar.gz from a git repo?
[15:46] <ari-tczew> if you've got "debian  uupdate" in debian/watch, then uscan can extract file
[15:48] <MaikB78> ok, I'll read the man page on uupdate
[15:49] <joaopinto> I am puzzled about apparmor-profiles, it's on universe but maintaned by coredevs, is that expected ?
[15:49] <joaopinto> aren't all universe packages MOTU maintained ?
[15:49] <ari-tczew> dunno
[15:54] <sistpoty|work> joaopinto: source is in main, maybe some archive inconsistency
[15:55] <MaikB78> ari-tczew: I confused by this get-orig-source vs uscan (debian/watch) business regarding fetching sources from the upstream VCS.
[15:55] <MaikB78> It there a golden way to do it?
[15:56] <ari-tczew> I prefer to updating packages manually, so I can't help you now.
[15:56] <joaopinto> sistpoty|work, ah ok, the binary is on universe
[15:57] <MaikB78> mkay
[15:57] <MaikB78> ari-tczew: thx
[16:03] <joaopinto> sistpoty|work, should I file a bug report about it ?
[16:03] <kees> jdstrand: that's an interesting thought.
[16:04] <sistpoty|work> joaopinto: no need to. afaict archive-admins have tools to detect such inconsistencies and fix them
[16:04] <joaopinto> ok
[16:04] <sistpoty|work> (so they're at least aware of it)
[16:05] <ari-tczew> sistpoty: maybe you know what about epiphany-gecko? is it no longer support by karmic? only -webkit?
[16:05] <sistpoty|work> ari-tczew: no idea about epiphany, sorry
[16:06] <ari-tczew> yhym so what the persion who know?
[16:06] <sebner> ari-tczew: it has been ported to -webkit by GNOME folks. gecko = dead
[16:07] <ari-tczew> I need info whether I should support gecko on webkit
[16:07] <ari-tczew> yhym so I should support webkit
[16:08] <ari-tczew> sebner: are you know that debian too drop support for gecko?
[16:08] <sebner> ari-tczew: unstable yes, testing no
[16:09] <ari-tczew> OK ;-)
[16:09] <ari-tczew> thnx
[16:11] <ari-tczew> who knows about forwarding packages to Debian?
[16:11] <ari-tczew> non-maintainer-upload vs new upstream version...
[16:32] <ari-tczew> .
[16:40] <surfzoid> directhex: me again :-), where are the rules for "make: *** No rule to make target `dh_clideps', needed by `binary'.  Stop"  ?
[16:41] <surfzoid> or perhaps i put it at the bad place :-/
[16:42] <joaopinto> surfzoid, you are missing a tab, to put inside the rule
[16:43] <surfzoid> hum i put it in the rule file like that : binary: binary-indep binary-arch dh_clideps
[16:45] <surfzoid> joaopinto: ^ i think i just understand , it was in the rule "binary-arch" i must add it :-)
[16:54] <Laney> what happens to motu-council after archivereorg?
[17:13] <ari-tczew> kees: are you here?
[17:13] <kees> ari-tczew: yup
[17:15] <ari-tczew> could you tell me what we can't get drupal 5.2.0 into karmic? why only small patches?
[17:16] <kees> ari-tczew: from http://wiki.ubuntu.com/KarmicReleaseSchedule we are in "FeatureFreeze".  If you want to get 5.2.0 into karmic, you'd need to follow the exception process: https://wiki.ubuntu.com/FreezeExceptionProcess
[17:18] <ari-tczew> so debdiff with small patches are easier get into karmic?
[17:18] <ari-tczew> I can prepare it
[17:19] <kees> ari-tczew: correct; if they are limited bug-fix patches, it's easy to upload
[17:20] <ari-tczew> I'll include only patches fixing critical security vulnerability
[17:24] <ari-tczew> anyone knows what about maven?
[17:24] <ari-tczew> any news?
[18:05] <directhex> woo woo
[18:52] <randomaction> thanks for merging hugin guys
[20:30] <funkyHat> I've got a fix for bug #444750 but there are a few other obvious keyboard shortcuts that are missing. Should I just fix them and add them to the same patch, or file a separate bug?
[20:31] <joaopinto> funkyHat, I am not a MOTU, but mu oppinion is a single bug, to reduce administrative work, assuming you use standard bindings which are not subject of debate :P
[20:35] <fabrice_sp_> funkyHat, agree with joaopinto
[20:35] <chrisccoulson> funkyHat - if there are others missing and you can fix them easily, then please do it all in one bug :)
[20:36] <funkyHat> Ok, I will add ^X, ^A, ^Q, ^W, ^O and ^P then, hehe
[20:38] <chrisccoulson> thanks
[20:39] <Laney> please send the fixes upstream too
[20:39] <funkyHat> Will do
[20:42] <micahg> ScottK: kvpnc built fine with debhelper kde disabled
[21:02] <jbernard_> fabrice_sp_: I posted an update for bug #443241
[21:04] <av`> fabrice_sp_, I don't think adding a patch system is bad
[21:05] <av`> fabrice_sp_, patching the files that way will make losing the changes at the next upstream release, plus it will be harder for the next uploader to catch the changes
[21:06] <av`> fabrice_sp_, saying the debdiff looks bigger is not a good motivation to reject a patch system IMO
[21:06] <jbernard_> you guys tell me, i have patches for both solutions
[21:06] <av`> fabrice_sp_, making the patch and forwarding it to debian is the way to go
[21:07] <av`> jbernard_, this is my personal opinion, fabrice_sp_ might think it different ;)
[21:07] <jbernard_> both solutions are attached to the bug, so you're free to choose
[21:09] <Viking667> hm. What's "MOTU" stand for?
[21:10] <lesshaste> I need to apply a patch to X. Is there a simple guide to patching and recompiling X for ubunt
[21:10] <lesshaste> u
[21:13] <geser> Viking667: Masters Of The Universe
[21:13] <Viking667> lol. Right. Kind of makes sense in a warped kind of way.
[21:50] <fabrice_sp_> jbernard_, av` I already had that discussion, and it's generally prefered not to add a patch system. It's general consensus.
[21:50] <av`> fabrice_sp_, we are not doing NMUs here
[21:51] <fabrice_sp_> av`, I know
[21:51] <fabrice_sp_> but we are not also here to redo all the debian packaging
[21:51] <fabrice_sp_> as I said before, it's a general consensus
[21:51] <av`> fabrice_sp_, redo? two changes are a redo?
[21:52] <av`> fabrice_sp_, saying the debdiff looks bigger / increase the difference between debian and ubuntu is not true and it's not a good motivation either
[21:52] <fabrice_sp_> it clearly increase the diff with debian, so will make a bit more 'coplex' the merge, if any
[21:53] <av`> fabrice_sp_, the first suggestion should be forward it to debian to have it applied then
[21:53] <fabrice_sp_> when I was sponsored, this is what I've been told by several sponsors. It's not my invention
[21:53] <fabrice_sp_> or both: apply in Ubuntu, and also forward
[21:54] <fabrice_sp_> it's just a matter of taste
[21:54] <av`> fabrice_sp_, having a package that will show changes to the source won't be the best to merge anyway
[21:54] <av`> moreover if it's not the only change and if the changelog is not well documented
[21:55] <av`> someone can mess everything up
[21:55] <fabrice_sp_> a debdiff will contains the same line, but in a different way
[21:55] <av`> fabrice_sp_, how do I know that a particular change to the source fixes Bug xx or Bug xxx?
[21:55] <av`> everything will be mixed up
[21:55] <fabrice_sp_> most of the time, Debian maintainer already did changes in the source
[21:56] <fabrice_sp_> I don't remember if it's the case of this particular package
[21:56] <av`> saying most of the case don't solve the problem
[21:56] <fabrice_sp_> you can mix up also everything with a 'bad' patch
[21:56] <av`> fabrice_sp_, as far as a developer review a patch is hard
[21:57] <fabrice_sp_> I personally prefer to review 5 lines, instead of 100
[21:57] <av`> fabrice_sp_, if you modify the source, the same lines will appear on a patch
[21:57] <fabrice_sp_> as I told you before, this is a general consensus, and not only my personal view
[21:57] <av`> with like 3-4 lines more for the rules/control
[21:57] <fabrice_sp_> and the rules
[21:57] <fabrice_sp_> and README.source
[21:58] <av`> readme.source? would you add a that with a patch system which is quilt or dpatch?
[21:58] <ari-tczew> fabrice_sp_: thnx for sponsoring hugin, but what about kadu?
[21:58] <fabrice_sp_> in the case of that bug report, the first debdiff is 190 lines long
[21:58] <stefanlsd> av`: i guess one of the reason is that in the general case the 'maintainer' is in debian. he has the right to employ or not employ a patch system as he sees fit
[21:58] <fabrice_sp_> according to policy 3.8.3, yes
[21:59] <av`> stefanlsd, I agree, but do you think the best choice is to patch sources directly?
[21:59] <fabrice_sp_> ari-tczew, it's a sync, so it has to be perfomed by archive admin, even if I acked it
[21:59] <av`> fabrice_sp_, there are some discussions to remove it for quilt / dpatch already ;)
[21:59] <stefanlsd> av`: you could send him a patch to add a patch system, but he might not choose to use it. if he doesnt use it, we have a delta between debian and us which is even more painful to maintain
[22:00] <fabrice_sp_> of course, the change has to be sent to Debian
[22:00] <av`> stefanlsd, well no, in the case he adds a patch system it means out patches are now integrated
[22:00] <av`> stefanlsd, so we can directly sync
[22:00] <fabrice_sp_> but only the change/patch, not everything, so submittodebian makes a cleaner job
[22:00] <av`> stefanlsd, we wouldnt need to change the patch system, if all patches are integrated
[22:01] <av`> stefanlsd, we simply drop the delta
[22:01] <fabrice_sp_> in this case, Debian does not have a patch system
[22:01] <stefanlsd> av`: yeah, i realise this, but you assuming the maintainer wants to use the patch system
[22:01] <fabrice_sp_> if you want to sponsor the patch system version, you can
[22:02] <fabrice_sp_> I mean, I'm not the only one sponsoring things :-)
[22:02] <av`> stefanlsd, he is free to choose whatever he wants
[22:02] <av`> stefanlsd, but if our changes are integrated into debian we drop the delta anyway
[22:02] <av`> stefanlsd, so again no point in patching the source
[22:02] <fabrice_sp_> wih or without patch system
[22:02] <fabrice_sp_> it's the same
[22:02] <av`> fabrice_sp_, no, don't wanna steal your work :)
[22:03] <fabrice_sp_> av`, which work :-)
[22:03] <av`> fabrice_sp_, feel free to upload, I alwais use patch systems, so I was trying to know why you told him to patch the sources directly ;)
[22:03] <fabrice_sp_> I'm scared by the ore than 1000 packages that still FTBFS...
[22:03]  * av` too
[22:04] <fabrice_sp_> that's what I did before Daneil, and others sponsors told menot to do so
[22:04] <stefanlsd> av`: yeah, i'd say, until he does, stick to whatever is currently being used. if he doesnt integrate it, we have much more work on our hands as the diffs look completely different now...
[22:04] <stefanlsd> there is also some really good arguments against patch systems (i cant argue them tho)
[22:04] <av`> stefanlsd, but what would you do if there are more than 'one fix' to apply?
[22:04] <av`> stefanlsd, I have 10 fixes around the code and I wanna apply them
[22:04] <fabrice_sp_> AFAIK, most core dev are against patch systems :-)
[22:05] <stefanlsd> and i think when workflows are using vcs like bzr, then we def dont want them
[22:05] <av`> stefanlsd, then the next merger would start being crazy trying to get what the previous uploader did
[22:05] <av`> stefanlsd, and to find out which fix is the one related to the foo.h or bar.c files
[22:05] <stefanlsd> looking at diffs with patches in is also very confusing (but maybe thats just me)
[22:05] <fabrice_sp_> in that case, it would cleaner, you're right, but if your 10 fixes fixes the same problem, they would be in the same patch anyway.
[22:06] <fabrice_sp_> all rely on the changelog, yes
[22:06]  * fabrice_sp_ is confused by diff with patches, and all that +-+-
[22:06] <stefanlsd> not just me :)
[22:06] <fabrice_sp_> no :-)
[22:07] <fabrice_sp_> have to go to have some rest. Bye :-)
[22:07] <av`> cya, have fun! :)
[22:07] <fabrice_sp_> thanks :-)
[22:07] <av`> np
[22:07] <fabrice_sp_> and if you want, freetalk is waiting for you ;-)
[22:10] <jbernard_> what is the consensus here? I have several FTBFS patches, but the diffs all rely on the outcome of this discussion
[22:10] <av`> jbernard_, fabrice gonna take care of it :)
[22:11] <jbernard_> but in general, ubuntu prefers modifying upstream as apposed to introducing a patch system?
[22:11] <jbernard_> or vise versa?
[22:12] <stefanlsd> jbernard_: i believe the consensus is 'stick to what the package currently uses'. so if it uses quilt, do quilt patches, if it patches source, just patch source.
[22:13] <stefanlsd> av`: you guys are welcome to take this up on the motu mailing list for input from all motu's
[22:13] <jbernard_> and the case where upstream is still pristine but no patch system is present?
[22:13] <av`> stefanlsd, the problem is when there's nothing set yet e.g when there are no patches
[22:13] <geser> jbernard_: if no patches are applied on the package you might add a patch system
[22:14] <geser> just make sure you don't end with a mix of quilt/dpatch patches and other patches applied directly
[22:14] <jbernard_> yep, this was the case with freetalk
[22:15] <stefanlsd> yeah. also for packages that are  -0ubuntuX (maintained by ubuntu), if there is none, you can make the call.
[22:16] <jbernard_> so the consensus seems to be that adding the patch system was the correct call
[22:16] <jbernard_> (in this case)
[22:16] <av`> stefanlsd, don't think mailing the MOTU list would change things, everyone can decide what to do as per package
[22:17] <ajmitch_> but as a group, there can be a general agreement on what's done
[23:49] <micahg> aptitude is showing me that 539MB will be freed if I update grub from 0.97-29ubuntu57 to 0.97-29ubuntu58