=== lamont` is now known as lamont [00:38] What is it that keeps changelogs lagging so much in publication? Why would they be anything but simultaneous to package publication? === a1g_ is now known as a1g [01:16] Heh, there's a needs-packaging bug for launchpad. === yofel_ is now known as yofel [02:47] Depends: autopano-sift-c | autopano-sift [02:47] ^ That'll install autopano-sift-c if it's available, and only autopano-sift if autopano-sift-c isn't available, right? [02:50] Darxus: correct, it also allows another package to /provide/ autopano-sift and satisfy the depend [02:53] jbernard_: Thanks. [02:54] 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] (hugin 2009.2.0). [02:54] Actually... it would be good if the hugin 0.8.0 package did that too :/ [02:54] Nah, that doesn't matter. [02:58] Er, kernel packages don't have "kernel" in the package name anymore? [03:00] Ah, "linux-image". Weird. [03:02] 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] dunno [03:06] Wow, kernel packages don't use quilt. [03:06] Darxus: on Ubuntu kernel=linux might be true, but e.g. on Debian it might be "hurd" or "kfreebsd" too I think ;) [03:07] 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] Although shortening the package names after putting the more useful "image" vs "headers" in there makes sense. [03:08] I guess some kernel package names are too long already... [03:11] - NAME = Man-Eating Seals of Antiquity [03:11] ^ Ubuntu kernel package. [03:13] Wow, I just realized the kernel packages are fully synked from debian, no patching. [03:15] 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] Or just 2.6.31-11.38-bfs303 ? [03:28] Darxus: want you get patched kernel into ubuntu repos? [03:29] ari-tczew: Eventually. [03:29] I guess it's impossible :) [03:29] ? [03:29] eventually, you can send patched kernel on your ppa [03:30] 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] yhym [03:31] or other way you can open bug for request apply patch (bfs303?) [03:32] btw. what about hugin? I saw that you're working on merge from experimental (?) [03:32] The bug is open, bug #424927 [03:32] Launchpad bug 424927 in linux "[needs-packaging] include Brain Scheduler" [Wishlist,Confirmed] https://launchpad.net/bugs/424927 [03:33] 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] 0.8.0 needs sponsor [03:34] like a libpano [03:34] Hmm, I thought that would've been taken care of by now :/ [03:35] not yet [03:36] if it's have been taken care, status should be a "Fix released" [03:36] Ah, right. [03:37] *Wow*, the debian diff against the linux kernel .orig is 295,602 lines. [03:38] Ah, this is ubuntu specific. Weird that ubuntu isn't in the version number. [03:40] 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] Ubuntu doesn't use the Debian kernel, but packages it's own, so the ubuntu would be pointless. [03:44] ScottK: could you upload libpano to universe? [03:45] ScottK: Ah, cool, thanks. [03:45] ari-tczew: Perhaps later. What bug? [03:46] bug 440177 [03:46] Launchpad bug 440177 in libpano13 "[FFe] Sync libpano13-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/440177 [03:49] ScottK: maybe you know, ubuntu now longer support epiphany-browser (gecko)? only -webkit? [03:49] ari-tczew: I don't. I'm a Kubuntu user [03:50] OK [03:51] 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] Kernel compiles should display an eta. Or at least percentage complete. [03:53] -gecko is out-of-dated. webkit is 2.28 [04:07] I found a dependency was not incremented properly in debian so now ubuntu doesn't knwo the correct version for a package [04:07] what to do? [04:10] ScottK: are you around? [04:11] micahg: I am. What's up? [04:12] It seems like kvpnc is FTBFS becuase the dependency on pkg-kde-tools was not bumped to 0.5.0 minimum [04:12] we have 0.4.11 [04:13] latest is 0.5.1 [04:15] sorry, I'm on an overlapping wireless channel at the moment [04:15] ScottK: any idea what I should do? [04:17] 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] ScottK: no, the failure is because a needed file was added in 0.5.0 [04:18] or at least the build thinks it needs it [04:18] I cannot ascertain if it's actually necessary [04:18] http://launchpadlibrarian.net/33004646/buildlog_ubuntu-karmic-i386.kvpnc_0.9.3-1_FAILEDTOBUILD.txt.gz [04:18] It's a valid packaging bug in any case [04:19] so should I file a sync request against pkg-kde-tools? [04:19] micahg: I see what you mean. [04:20] I thought we had 0.5 something [04:21] ok, hopefully that fixes my wireless issue [04:21] ScottK: what did I miss? [04:22] micahg:What's the last thing you saw from me? [04:22] (10:18:26 PM) ScottK: It's a valid packaging bug in any case [04:23] micahg: OK. I also said that I'd thought we had 0.5 something and I see we don't. [04:24] ok, well that seems to be the issue [04:24] 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] 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] this is ridiculous, I apologize [04:27] Oh? [04:27] my wireless droppiong like this [04:27] so, what should I do? [04:28] [23:24:19] 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] [23:24:46] 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] micahg: Get it that time? [04:28] yes [04:28] it's a perl module that's missing [04:28] so, I should include that in the kvpnc package? [04:29] micahg: I'd try that first [04:29] hmm, I've never done this before, but I'll give it a shot, might take me a day or two [04:30] OK [04:32] 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] nevermind, I should probably just use it and not install it [05:20] Darxus: Doing a lot is easy. Being minimally invasive is a challenge. [05:21] Heh. [05:23] ScottK, do you think you will have time to upload Bug #440177? [05:23] Launchpad bug 440177 in libpano13 "[FFe] Sync libpano13-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/440177 [05:24] just to know if I retain hugin 0.8.0 upload until it's uploaded or not [05:26] fabrice_sp_: I'm looking at it now. [05:26] cool. thanks :-) [05:26] I thought you uploaded hugin already? [05:31] 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] ScottK, I just wanted to build it locally, just to be sure it builds fine, and run fine [05:32] OK. [05:32] will test it today then :-) Thanks! [05:32] (again :-) ) [05:33] OK. [05:56] ScottK: ok, I think I got it [05:56] test build in my ppa in an hour hopefully [06:22] hyperair, do you really needs sponsoring for bug #442328? :-D [06:22] Launchpad bug 442328 in ipod-sharp "Sync ipod-sharp 0.8.3-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/442328 [06:22] fabrice_sp_: sure i do. from an archive admin, that is =) [06:22] i've got motu-release ACKs and uus ACK from directhex [06:30] uus? ahh: I thought you were a MOTU :-/ [06:31] my bad :-) [06:32] I've just subscribed archive-admin [07:10] good morning === nxvl_ is now known as nxvl [07:13] good morning dholbach ! [07:14] hola fabrice_sp_ [07:14] hey guys i have a kernel packaging question, is this the appropriate place to ask ? [07:14] #ubuntu-kernel will probably give you better answers :) [07:15] 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] they might be sleeping now [07:18] porthose, ping [07:18] swoody, pong [07:18] porthose, just got your email [07:18] 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] swoody, is emgent still mentoring you? [07:19] 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] I don't remember anyone by the name of emgent, though [07:20] 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] mase_wk: dholbach at ubuntu dot com [07:20] so short answer, no I'm not a mentee, but I would still be interested in becoming a MOTU, still. [07:21] dholbach: ok thanks. === MTecknology is now known as MTeck === MTeck is now known as MTecknology [07:35] ScottK: you wouldn't happen to still be up, would you? === micahg1 is now known as micahg === Lutin_ is now known as Lutin [08:23] I am looking for documentation on: [08:23] /usr/share/python-support/python-foo.public [08:23] I think it is something new in the last version of dh_pysupport [08:23] is it right? [08:26] logari81: /usr/share/doc/python-support/README.gz (what's not there, you should not touch) === porthose is now known as porthose|afk === dholbach_ is now known as dholbach [10:14] 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] ** how [10:15] surfzoid, deb http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu/xUbuntu_9.04/ ./ [10:15] surfzoid, i think [10:16] ha yes i dont think about ./, the proble was amd64-binary :-) [10:16] jms@osc-franzibald:~/Desktop/mitter-0.4.5$ apt-cache policy monoosc | grep Candidate [10:16] Candidate: 1.0.2.0 [10:16] seems to work [10:17] directhex: work like a charm :-) [10:24] directhex: again :-), the repository is added without error, but i don't see my soft in synaptic [10:25] surfzoid, synaptic's always been a bit funny for me. can't make any suggestions [10:27] did you reload the index? (I think that's synaptic terminology) [10:29] i used the refresh cache/aviabe pkg function [10:29] hum, the update tool see some pkg of my repo !! [10:34] seem to be an author problem, pkg are not authentified !! what can i do ? === doko__ is now known as doko [10:57] 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] how i register the dll in the gac and how the dep list is made !! [10:58] 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] 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] build-depend is not only the build requiere but also the requiere ? [11:01] hello all [11:01] i am looking for an mentor [11:02] 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] oki [11:03] 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] maco, you even got a personal mention from Mikee! lucky you! ¬_¬ [11:25] he can't spell though === porthose|afk is now known as porthose [13:10] hello, I'm looking sponsor for universe to 2 bugs [13:17] ari-tczew https://wiki.ubuntu.com/SponsorshipProcess [13:31] * mok0 just upgraded his workstation to karmic. That was a harrowing experience [14:21] Hello [14:22] 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] Yes [14:22] ok [14:22] but how to do it with cdbs? [14:23] I came across this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494141 [14:23] Debian bug 494141 in cdbs "no way to use get-orig-source with cdbs without breaking policy" [Normal,Open] [14:23] which gives me the impression cdbs doesn't work with the get-orig-source hook [14:24] MaikB78, it does, just not as expected, from any dir [14:25] joaopinto: I fear I didn't get what exactly you mean. Are there examples around? [14:26] I did this stuff a lot in gentoo and arch. I'd love to get it work on ubuntu/debian [14:27] by example I mean: Which if the *~svn1234 packages are using cdbs? [14:28] doko: do you have eclipse already uploaded? [14:28] 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] bdrung_: yes, but we can still update [14:29] doko: did you grab it from the git repo or from the ppa? [14:29] bdrung_: ppa [14:29] joaopinto: will, thx again! [14:30] doko: did you adjust the changelog? [14:30] bdrung_: what do you mean? [14:31] bdrung_: see https://lists.ubuntu.com/archives/karmic-changes/2009-October/010369.html [14:31] doko: did you upload it with -0~ppa1? [14:32] doko: fyi, i can upload to universe, too [14:32] bdrung_: ok, the next uploads are yours! [14:34] doko: which value does DEB_HOST_ARCH_CPU have on lpia? [14:35] i686 [14:35] bdrung_: I did attach a patch to my email [14:36] doko: yes, saw it. that's why i asked [14:37] doko: we have only i386 and amd64 machines and no access to others. [14:38] doko: the main discussions are in #debian-java and some are in #eclipse-linux [14:38] bdrung_: I know [14:39] 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] doko: btw, thanks a lot for working on maven! :) [14:43] 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] sistpoty|work: so better pester ScottK & co ;) [14:44] doko: ScottK just gave an ack for the FFe ;) [14:45] ScottK: any plans with xz-utils? else I'd like to upload the fix for the data corruption [14:45] doko: fix applied, thanks. [14:47] doko: Please fix that. [14:48] 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] 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] directhex: make: dh_installcligac: Command not found ? [14:57] surfzoid, it's in cli-common-dev [14:57] so in to add in dep buil [14:58] thanks [14:58] I guess this is the right one for uscan: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch [15:13] directhex: yes i know [15:14] 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] maco, seems a bit of a knob, tbh [15:14] 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] directhex: he has a TON of fake names, by the way [15:15] directhex: i'm pretty sure you hit a fake one [15:15] maco, he's rather slippery. tor doesn't help. [15:16] directhex: PM? [15:16] hm? oh, yes, getting a bit offtopic [15:16] arand: are you referring to the 'urgency' field in the changelog? [15:18] yeah, what about that field, it is always "low" [15:18] * slacker_nl is curious as well [15:18] jdstrand: not perfectly sure to be honest, I would think so. [15:19] it means nothing in Ubuntu. it is used in Debian to prioritize builds iirc [15:19] aha [15:19] why doesn't ubuntu use it? Is it not handy to b eable to prioritize builds? [15:20] we have a different build system [15:20] security builds are given the highest priority [15:20] it's not buildds as such, but testing migration [15:20] urgency is mostly for unstable->testing isn't it? [15:20] and we don't have a "testing" suite [15:20] aha, thought so. HIGH FIVE! [15:21] ahh, k [15:21] james_w: interesting-- so that field was introduced when 'testing' first came about? [15:21] what was that... wodody? [15:21] I believe so [15:21] woody [15:22] cool [15:22] it may be used for builds as well, but that's not it's main purpose [15:22] * jdstrand learned something new :) [15:22] it is in fact used for build priorities in Ubuntu, but no-one ever sets it [15:22] haha [15:22] urgency=OMG [15:22] james_w: I was always told it was ignored in Ubuntu. when did this change? [15:22] hehehe [15:22] jdstrand: hmm, yea, and it looks like that string is removed in jaunty update manager anyways... [15:22] and you're only talking a matter of hours at the most [15:23] jdstrand: no idea [15:23] directhex: urgency=EMERGENCY :P [15:23] * jdstrand considers letting james_w field this sorts of questions [15:23] file:///usr/share/doc/debian-policy/policy.html/ch-controlfields.html#s-f-Urgency [15:23] that should've been http... [15:24] Yea, launchpad help says it will effect build priority, but by a minuscule bit iirc [15:24] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Urgency [15:24] and there you go: [15:24] 36 [15:24] 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] 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] https://help.launchpad.net/Packaging/BuildScores [15:25] james_w, how about urgency=prettyplease where a PPA gets >archive priority due to politeness? [15:25] Heya gang [15:25] low-5 med-10 high-15 emergency-20 [15:26] hi bddebian [15:26] Heya sistpoty|work [15:26] But then the priority has nothing to do with the contents of the package? Only with the build priority? [15:27] 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] doko: we need an updated cdt, too. [15:29] 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] probabl [15:30] bdrung_: yes [15:30] arand, james_w: there are official builders for Ubuntu that are separate from PPA builders [15:30] doko: is there someone, who maintains it? [15:30] it is designed so one can't does Ubuntu via a PPA builders [15:31] s/does/DoS/ [15:39] bdrung_: no, just synced from debian [15:43] Am I right that uscan doesn't know how to extract a tar.gz from a git repo? [15:46] if you've got "debian uupdate" in debian/watch, then uscan can extract file [15:48] ok, I'll read the man page on uupdate [15:49] I am puzzled about apparmor-profiles, it's on universe but maintaned by coredevs, is that expected ? [15:49] aren't all universe packages MOTU maintained ? [15:49] dunno [15:54] joaopinto: source is in main, maybe some archive inconsistency [15:55] ari-tczew: I confused by this get-orig-source vs uscan (debian/watch) business regarding fetching sources from the upstream VCS. [15:55] It there a golden way to do it? [15:56] I prefer to updating packages manually, so I can't help you now. [15:56] sistpoty|work, ah ok, the binary is on universe [15:57] mkay [15:57] ari-tczew: thx [16:03] sistpoty|work, should I file a bug report about it ? [16:03] jdstrand: that's an interesting thought. [16:04] joaopinto: no need to. afaict archive-admins have tools to detect such inconsistencies and fix them [16:04] ok [16:04] (so they're at least aware of it) [16:05] sistpoty: maybe you know what about epiphany-gecko? is it no longer support by karmic? only -webkit? [16:05] ari-tczew: no idea about epiphany, sorry [16:06] yhym so what the persion who know? [16:06] ari-tczew: it has been ported to -webkit by GNOME folks. gecko = dead [16:07] I need info whether I should support gecko on webkit [16:07] yhym so I should support webkit [16:08] sebner: are you know that debian too drop support for gecko? [16:08] ari-tczew: unstable yes, testing no [16:09] OK ;-) [16:09] thnx [16:11] who knows about forwarding packages to Debian? [16:11] non-maintainer-upload vs new upstream version... === captivus is now known as Guest90030 === Pici is now known as Guest99641 === Guest99641 is now known as Pici === txwikinger2 is now known as txwikinger_work === soren_ is now known as soren === jmarsden_ is now known as jmarsden === ssweeny_ is now known as ssweeny === kmdm is now known as Guest66260 [16:32] . [16:40] directhex: me again :-), where are the rules for "make: *** No rule to make target `dh_clideps', needed by `binary'. Stop" ? [16:41] or perhaps i put it at the bad place :-/ [16:42] surfzoid, you are missing a tab, to put inside the rule [16:43] hum i put it in the rule file like that : binary: binary-indep binary-arch dh_clideps [16:45] joaopinto: ^ i think i just understand , it was in the rule "binary-arch" i must add it :-) [16:54] what happens to motu-council after archivereorg? [17:13] kees: are you here? [17:13] ari-tczew: yup [17:15] could you tell me what we can't get drupal 5.2.0 into karmic? why only small patches? [17:16] 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] so debdiff with small patches are easier get into karmic? [17:18] I can prepare it [17:19] ari-tczew: correct; if they are limited bug-fix patches, it's easy to upload [17:20] I'll include only patches fixing critical security vulnerability === tgm4883` is now known as tgm4883 [17:24] anyone knows what about maven? [17:24] any news? === jdong__ is now known as jdong === Philip6 is now known as Philip5 [18:05] woo woo === jldugger is now known as pwnguin === slangase` is now known as slangasek [18:52] thanks for merging hugin guys [20:30] 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:30] Launchpad bug 444750 in gpaint "[papercut] CTRL-V doesnt paste in gpaint" [Undecided,New] https://launchpad.net/bugs/444750 [20:31] 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] funkyHat, agree with joaopinto [20:35] funkyHat - if there are others missing and you can fix them easily, then please do it all in one bug :) [20:36] Ok, I will add ^X, ^A, ^Q, ^W, ^O and ^P then, hehe === nicolasv` is now known as nicolasvw [20:38] thanks [20:39] please send the fixes upstream too [20:39] Will do [20:42] ScottK: kvpnc built fine with debhelper kde disabled [21:02] fabrice_sp_: I posted an update for bug #443241 [21:02] Launchpad bug 443241 in freetalk "freetalk FTBFS" [Low,New] https://launchpad.net/bugs/443241 [21:04] fabrice_sp_, I don't think adding a patch system is bad [21:05] 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] fabrice_sp_, saying the debdiff looks bigger is not a good motivation to reject a patch system IMO [21:06] you guys tell me, i have patches for both solutions [21:06] fabrice_sp_, making the patch and forwarding it to debian is the way to go [21:07] jbernard_, this is my personal opinion, fabrice_sp_ might think it different ;) [21:07] both solutions are attached to the bug, so you're free to choose [21:09] hm. What's "MOTU" stand for? [21:10] I need to apply a patch to X. Is there a simple guide to patching and recompiling X for ubunt [21:10] u [21:13] Viking667: Masters Of The Universe [21:13] lol. Right. Kind of makes sense in a warped kind of way. === Quintasan1 is now known as Quintasan === micahg1 is now known as micahg [21:50] jbernard_, av` I already had that discussion, and it's generally prefered not to add a patch system. It's general consensus. [21:50] fabrice_sp_, we are not doing NMUs here [21:51] av`, I know [21:51] but we are not also here to redo all the debian packaging [21:51] as I said before, it's a general consensus [21:51] fabrice_sp_, redo? two changes are a redo? [21:52] 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] it clearly increase the diff with debian, so will make a bit more 'coplex' the merge, if any [21:53] fabrice_sp_, the first suggestion should be forward it to debian to have it applied then [21:53] when I was sponsored, this is what I've been told by several sponsors. It's not my invention [21:53] or both: apply in Ubuntu, and also forward [21:54] it's just a matter of taste [21:54] fabrice_sp_, having a package that will show changes to the source won't be the best to merge anyway [21:54] moreover if it's not the only change and if the changelog is not well documented [21:55] someone can mess everything up [21:55] a debdiff will contains the same line, but in a different way [21:55] fabrice_sp_, how do I know that a particular change to the source fixes Bug xx or Bug xxx? [21:55] everything will be mixed up [21:55] most of the time, Debian maintainer already did changes in the source [21:56] I don't remember if it's the case of this particular package [21:56] saying most of the case don't solve the problem [21:56] you can mix up also everything with a 'bad' patch [21:56] fabrice_sp_, as far as a developer review a patch is hard [21:57] I personally prefer to review 5 lines, instead of 100 [21:57] fabrice_sp_, if you modify the source, the same lines will appear on a patch [21:57] as I told you before, this is a general consensus, and not only my personal view [21:57] with like 3-4 lines more for the rules/control [21:57] and the rules [21:57] and README.source [21:58] readme.source? would you add a that with a patch system which is quilt or dpatch? [21:58] fabrice_sp_: thnx for sponsoring hugin, but what about kadu? [21:58] in the case of that bug report, the first debdiff is 190 lines long [21:58] 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] according to policy 3.8.3, yes [21:59] stefanlsd, I agree, but do you think the best choice is to patch sources directly? [21:59] ari-tczew, it's a sync, so it has to be perfomed by archive admin, even if I acked it [21:59] fabrice_sp_, there are some discussions to remove it for quilt / dpatch already ;) [21:59] 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] of course, the change has to be sent to Debian [22:00] stefanlsd, well no, in the case he adds a patch system it means out patches are now integrated [22:00] stefanlsd, so we can directly sync [22:00] but only the change/patch, not everything, so submittodebian makes a cleaner job [22:00]