[00:00] geser: is there a special command to generate a merge bugreport ? [00:00] dupondje: no [00:01] dupondje: and don't forget to close the bug in your changelog entry. this means: file a bug, insert the bug number into your debian/changelog, create debdiff, attach debdiff to bug [00:02] Could someone please review http://revu.ubuntuwire.com/p/turnin-ng (simple python application, both turnin-ng_1.0.1-0ubuntu1_source.changes and turnin-ng_1.0.1-0ubuntu1_i386.changes are lintian -IivmE --pedantic clean) [00:04] geser: oops, thanks. [00:05] ryanakca: does it only work with python 2.6? [00:05] geser: No, python2.5 as well [00:06] geser: switch to python (>= 2.5) in control and 2.5-2.6 in pyversions ? [00:06] ryanakca: then 2.5- in debian/pyversions would be better (if I remember the syntax correctly) [00:06] geser: Wouldn't that also let 3.x in? [00:06] ryanakca: No [00:06] or no, nevermind, pycompat takes care of that [00:07] geser: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/521217 [00:07] Ubuntu bug 521217 in gnucash "Merge gnucash 2.2.9-3 from debian sid" [Undecided,New] [00:07] There will be a seperate way to specify Python3 versions. [00:07] ryanakca: Also XS-Python-Version is preferred over pyversions. [00:07] ScottK: OK [00:07] ah damn, forgot to change maintainer ;) [00:08] ScottK: do you know if we keep python3.0 in the archive for lucid? [00:08] geser: I think not. I think just 3.1. [00:09] ScottK, geser: done [00:10] fixed :) [00:11] dupondje: we usually keep the old ubuntu changelog entries during merges (since the last real sync). I didn't check yet the ubuntu delta. did you check if it got merged or needs keeping? [00:13] geser: so I need to add old ubuntu changelogs ? I checked the patches, and everything got into sid [00:13] dupondje: if everything is in sid, do a sync, not a merge [00:14] lifeless: well everything that was in last real sync is now into sid. But I added a new patch for the version in sid [00:14] so its a merge ? [00:15] EPARSE [00:15] dupondje: sort of, a comment in the bug about your analysis of the ubuntu delta would be good [00:15] lifeless: all old ubuntu delta got into the Debian package -> sync but the package would FTBFS without a new patch [00:16] ah [00:16] I'd do a sync, let it FTBFS, and then a new ubuntu patch [00:16] dupondje: and don't forget to subscribe the sponsors-team [00:16] geser: all fine as expected, now I can just upload, or do I need to bzr push? [00:17] sistpoty: bzr commit [00:17] geser: already done that [00:17] bzr mark-uploaded [00:17] bzr push lp:ubuntu/mknbi [00:17] and upload the build package [00:18] the push will mark the merge-proposal as merged (else I have to update the status myself) [00:19] lifeless: no sponsor will ACK a sync for a package that will FTBFS (and why waste build time when we know that it will fail?) [00:19] geser: ok, done all that, thanks a lot! [00:19] sistpoty: until we get "BuildFromBranch" into the archive one has to push and upload [00:20] sistpoty: hi, are you active on IRC if development cycle going to FFe? [00:20] (I must admit that that's the most complicated form I've seen so far to review a *simple* debdiff) [00:21] hi ari-tczew, depends on how much time I can find when at work, but most probably I'll be around (but not too responsive, due to work responsibilities) [00:21] sistpoty: if would have wanted a simple debdiff, I could have provided it [00:21] geser: then I wouldn't have learned the bzr magic ;) [00:22] geser: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/521217 => added ubuntu changelogs + more info for the merge [00:22] Ubuntu bug 521217 in gnucash "Merge gnucash 2.2.9-3 from debian sid" [Undecided,New] [00:22] geser: I think bzr really comes in handy for more complicated things, and you got me curious to find out ;) [00:23] geser: wanna sponsor? [00:23] sistpoty: you now know 2/3 of how to do bzr based merges too :) [00:24] ari-tczew: sponsor what? [00:24] How long do I have to get a new-upstream-point-release (which only fixes a "app crashes under very probable conditions" bug) sponsored into the archives? I assume after FinalFreeze that's not an option, but are there any other freezes I should be wary about? [00:24] geser: I assume, but many of my bzr knowledge is lost already, and I must admit that I never even touched a mom-prepared merge (I wanted to redo my changes from scratch... that often lead to recommenting bad changes or kicking out unnecessary changes) [00:25] sistpoty: bzr based merges work fine if the packaging branches are up-to-date (there are still several that fail at the package import level) [00:25] s/bad/underdocumented/ [00:25] geser: sync bug 521220 [00:25] Launchpad bug 521220 in kadu "Sync kadu 0.6.5.4-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/521220 [00:26] geser: I've seen siretart doing a bzr merge once, that impressed me quite a lot (though back then it also seemed a little bit like magic to me) [00:28] geser: because a) most packages get built more than once anyway, so its not like its a new thing [00:29] geser: and having a smaller more obvious delta against debian helps the next sync/merge cycle. [00:29] in such a case I wouldn't insist on keeping the old ubuntu changelog entries [00:30] bug I still would prefer to do 1 upload instead of a sync and patch later [00:31] geser: lifeless: it build if you sync from debian, but it breaks a function, that would need to be patched again then ... better do it in 1 merge then ? [00:31] it introduces http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567208 [00:31] Debian bug 567208 in gnucash "Gnucash 2.2.9-3 has no graphing support" [Serious,Open] [00:32] lifeless: uploading things that FTBFS both add load to the buildds (you *can* work around this by looking at the queue lenght) but it also means that you hinder anyone fixing bugs in a package [00:33] dupondje: a comment in the bug would be IMHO sufficient (so that the reviewer know that you checked it and not dropped the changes because you not yet familiar with merging) but adding it into the changelog entry is also ok [00:34] well now its clear anyway :D [00:34] lifeless: the tough thing is to consider if the ubuntu changes are really all included upstream wise. For some packages only the full debdiff can show that, and that's not quite unlikely to drop a change on error. having the full (ubuntu) changelog makes it extremely easier to find a dropped change [00:35] (that sentence was grammatically wrong) [00:35] sistpoty: thats what I'm saying, if the analysis has been done to determine 'nothing dropped' then doing a sync records that analysis [00:35] otherwise it gets larger and larger and harder to tell [00:35] particularly with upstream releases take patches [00:36] lifeless: only that for bigger changes the analysis might be wrong (ok, if a sync is already requested, there's no going back anyways) [00:37] lifeless: just FYI, I've been doing merges by actually rebasing anything against unstable, redoing all ubuntu changes and dropping changelog entries for a very long time [00:37] lifeless: until I was convinced (maybe with a pointy stick) that there is some value to keep old changelog entries ;) [00:39] it seems that the package is ok now , may someone confirms it ? please [00:39] http://revu.ubuntuwire.com/p/pms-linux [00:46] nite guys [00:46] thx for assistance :) [00:47] Anyone able to help debug a package file issue? I have a package that has stopped installing certain files. [00:48] I have the package freeswitch, and freeswitch-lua [00:48] freeswitch-lua depends on freeswitch, and f-lua will install a set of .so's and .la's but it isn't happening any more [00:48] I have extracted the f-lua.deb with dpkg-deb --extract... [00:49] and the files are there [00:49] they jsut aren't ever copied to the location... [00:49] it's driving me insane... I have no idea what could be going wrong... [00:51] lifeless, sistpoty ^ [00:52] quentusrex: .la files should generally get removed, let me dig the thread on debian-devel [00:53] generally yes, but not in this case. [00:53] but I am looking at the freeswitch.install file and it has a bunch of .so's that are getting installed [00:53] but the freeswitch-lua.install file has the list of files, but they aren't getting copied. [00:54] I see them in the debian/tmp/ directory when I build the package, and I see them in the debian/freeswitch-lua/... directory as well... [00:57] quentusrex: maybe the thread at http://lists.debian.org/debian-devel/2009/05/msg00441.html gives some clue? (not too sure if there are libtool changes referenced though) [00:57] I think I found something interesting: chroot-autobuild/build/buildd/freeswitch-lua_1.0.4+repack12-0ubuntu16625M.0~karmic_amd64.deb [00:58] that step [00:58] doesn't actually copy files... [00:58] it doesn't copy the .so's like the other steps do [00:59] http://launchpadlibrarian.net/39125363/buildlog_ubuntu-karmic-amd64.freeswitch_1.0.4%2Brepack12-0ubuntu16625M.0~karmic_FULLYBUILT.txt.gz [00:59] you can see if you search for the chroot line in that buildlog [00:59] just above that maybe 100 lines up [00:59] it copies .so's [00:59] but it doesn't for any other package. [00:59] that's my problem. [01:01] sistpoty, do you see what I mean? [01:01] quentusrex: not too sure what you're asking for, but there are plenty of .la-files in freeswitch-dev_1.0.4+repack12-0ubuntu16625M.0~karmic_amd64.deb [01:01] right [01:02] but in freeswitch-lua_1.0.4+repack12-0ubuntu16625M.0~karmic_amd64.deb there are no .so files [01:02] nor in -perl, or -spidermonkey [01:02] etc. [01:02] when there should be atleast a few in each. [01:02] does anyone know the cause of the following error when attempting to compile source using dpkg-buildpackage? "tail: cannot open `debian/changelog' for reading: No such file or directory" [01:03] quentusrex: I'm sorry, but I cannot really help you with ppa-related things. please ask in #launchpad [01:03] iclebyte: there's no debian/changelog? [01:04] no.. I'm attempting to build postfix-2.5.1 sources after applying the VDA quota patch. [01:05] sistpoty, the step's i've taken are here: http://ubuntuforums.org/showthread.php?t=1405550 - it's easier to point you to that than list them all here. [01:08] ScottK: ^^ reproducible with plain postfix as in the archives [01:09] * ScottK looks [01:09] ScottK: do missing build-depends result in that error? (as I don't have all b-d installed) [01:12] ScottK: looks like it, sorry for the noise [01:12] Ah. [01:12] iclebyte: you'll need all build-dependencies installed [01:13] iclebyte: hence an apt-get build-dep postfix [01:13] iclebyte: should fix the "problem" [01:13] iclebyte: For the record VDA is totally unsupported in Ubuntu or upstream. The patch was proposed to upstream, but did not meet upstream quality requirements. [01:13] I already did that... [01:14] iclebyte: others than that, if anything else but the *ubuntu source package* doesn't build, I'm sorry, but we cannot really help you here [01:15] sispoty: can you sponsoring for main? [01:15] ari-tczew: yes [01:16] cool! [01:16] ari-tczew: as in got a but number? [01:16] s/but/bug/ [01:17] sistpoty: not now, generally I'm going to do a debdiff for some fake syncs [01:17] okay, i've just deleted my patched version of the source and extracted the postfix_2.5.1.orig.tar.gz which was downloaded by executing 'apt-get source postfix'. I entered that directory and executed dpkg-buildsource and get the same error. Is this what you would expect or should it build? [01:17] there's also a postfix_2.5.1-2ubuntu1.2.diff.gz archive thats been downloaded with it too but i've done nothing with that manually [01:18] ari-tczew: ok [01:18] iclebyte: did you do an apt-get build-dep postfix? [01:19] i did both. [01:20] iclebyte: what version of Ubuntu are you running? [01:20] 8.04-LTS the server one. [01:22] iclebyte: let me try to reproduce the problem (takes some time, I'll need to create an 8.04 chroot first) [01:24] sistpoty, thanks very much! [01:24] * iclebyte might make a cup of tea and hang around a bit =) [01:31] sistpoty, I've fixed it! [01:32] because I've messed about with the source so many times, I've been extracting the postfix-orig tar manually, I removed everything and downloaded it again and apt-get source postfix applies the ubuntu diff which must stick the debian/ directory into the postfix source. now it builds. [01:33] (that's my assumption as to how it works anyway) [01:34] iclebyte: great [01:35] thankyou for your help though, it is much appreciated [02:05] hyperair: meh, I think I screwed bug #512358. I should have left it at confirmed but unsubscribed ubuntu-main-sponsors (which I cannot do) ;( [02:05] Launchpad bug 512358 in e2fsprogs "FTBFS: missing html files" [Undecided,New] https://launchpad.net/bugs/512358 [02:09] * sistpoty heads to bed now, gn8 everyon [02:09] +e [02:35] i see my package now in the site, but is it in the right place in order to get advocated ? [02:35] http://revu.ubuntuwire.com/p/pms-linux [02:36] is there something else to do ? [02:53] I want to build a pkg so I un-tarred the source put it into a dir called then entered that dir and did a dh_make [02:54] but it fails saying.. cannot understand the dir name [03:46] My package needs to modify /etc/xdg/user-dirs.defaults to add a PROJECTS stanza. As this isn't allowed by policy, would it be a good idea to modify the xdg-user-dirs package itself to have that by default, and if so, who should I ask about that? [04:22] We're looking for advice on bug 521263 can anyone lend a hand? [04:22] Launchpad bug 521263 in groundcontrol "GC postinst should not modify configuration files owned by other packages" [Undecided,New] https://launchpad.net/bugs/521263 [04:27] <3> is the most favorable solution [04:28] although you'll probably want to raise that with the freedesktop folks first [04:29] doctormo: see DPM §10.7.4: http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4 [04:29] superm1: which would be doable in time for FF? :) [04:30] lfaraone, well lob an email over to their mailing list and see how they feel about adding another directory to the spec [04:30] they wont have a new release in time probably, but if they agree to it, nothing is to stop you from backporting such a thing [04:31] which should be achievable in time for FF [04:31] and if not, I don't see why an FFe couldn't be done for something like this [04:31] superm1: well, groundcontrol isn't in Ubuntu yet. [04:36] lfaraone, that's okay. [04:37] lfaraone, the other thing i'd propose is maybe just choosing one of the existing xdg directories and making a subdirectory [04:37] doctormo: is that an acceptable alternative? [04:37] like $DOCUMENTS/Projects perhaps [04:37] doctormo: (assuming XDG says "no") [04:43] lfaraone: The alternative is that we pull out of XDG and disable ground control, letting people edit their own configs and own directories, making it really hard to install and a pointless endevour [04:43] doctormo: I mean, can't we have some better functionality to control whether groundcontrol is enabled or not than XDG settings? :) [04:44] You mean, display the projects banner on every nautilus folder [04:45] doctormo: no, default to something like $DOCUMENTS/Projects, and let it be configurable via say .config/groundcontrol/blah.ini [04:45] bleh, configs for directories, it's like they want to make this hard [04:46] What would create that folder [04:46] Why would that be default [04:46] That's not even how I organise my projects [04:46] projects aren't documents [04:48] doctormo: you're right. we could just ignore the XDG spec entirely and write to $HOME/Projects. [04:52] anyone who has a good understanding of the new source format online? and new bzr workflow too.. I'm trying to merge (or rather rebase) ubuntu transmission on the current unstable package and have some problems [04:53] there is debian/patches/.dpkg-source-applied and patches are indeed aplied but there is no .pc nowhere to be found in the branch - is it normal? [04:57] lfaraone: The cheese program creates a directory every time it runs, it's really annoying [04:57] and for many months I never knew why [04:57] It turns out it was because the XDG video directory pointed to my home folder [04:58] And it would magically make a directory Webcam every load [04:58] That's also a really bad idea [04:59] I don't actually mind using ~/Projects/lp/ instead of just ~/Projects, but it makes me very uncomfortable to ignore XDG when it's such a good spec, it just needs more flexibility. [06:59] I am a high school student. What are the qualifications I require to be a MOTU member? [07:03] [12:29] I am a high school student. What are the qualifications I require to be a MOTU member? Please help [07:03] ma10, https://wiki.ubuntu.com/MOTU#So%20you%20want%20to%20be%20a%20MOTU? [07:03] ai [07:03] maitraya, https://wiki.ubuntu.com/MOTU#So%20you%20want%20to%20be%20a%20MOTU? [07:04] thanks [07:06] maitraya, also see the topic (https://wiki.ubuntu.com/MOTU/Contributing) [09:53] would be nice if everybody will update its merges before FFe ! [09:53] 'its merges' <-- referring to what? [09:55] e.g. if you did 3 merges and now these merges are not updated, would be nice if you'll update these merges before FFe [09:58] what do you mean by "not updated"? [09:58] as in not uploaded yet? [09:58] or there are new merges to be done? [09:58] or what? [09:59] new merges [09:59] of course [09:59] ah [10:01] I uploaded one, waiting to be accepted :P [10:07] quadrispro: regarding codelite, are you interested in taking over maintainership of it? [10:07] quadrispro: i noticed you uploaded a new upstream release of codelite recently. [10:08] hi hyperair! yep, that release fixes a lot of issues [10:10] quadrispro: cool. in that case, could you keep the git packaging repository up to date, or move the packaging elsewhere? [10:10] hyperair, ah! you're right [10:10] no, I'll update the git repo [10:10] i've already updated it on your behalf =) [10:10] I didn't notice it before [10:11] =) [10:11] excellent :) [10:12] anyway, i'd have preferred if you had notified me before doing the upload. i began working on it on early this morning, only to realize that it was already done after my initial checks. (my uscan cronjob runs weekly on fridays) [10:13] is it available to do a merge past FFe? [10:14] quadrispro: you might also like trying to get codelite into debian, if you know someone who would upload it. [10:17] Hi ! If anybody has time, please have a look at enna package on revu (http://revu.ubuntuwire.com/details.py?upid=7713). It's a new cool Media Center :) Thank you ! [10:18] ari-tczew: yes, after FF you can do merges too, you just might need a FF exception when merging a new upstream version [10:19] geser: but if there are not new upstream version, just new release Debian version: do I should give a FFe reason? [10:22] no, but think if we need those changes before merging [10:37] Could someone please take a look at my package sciteproj - an project handler for SciTE - upstream http://sciteproj.sf.net, revu at http://revu.ubuntuwire.com/p/sciteproj . Thanks. [10:42] hyperair, ok [11:25] guys, my package does no appear in new packages ! ... in the http://revu.ubuntuwire.com/ site ... the package is pms-linux ^^ [11:26] why people uploading new packages to REVU instead Debian Mentors? [11:27] oh [11:28] they still have hope to get the package faster through REVU than Debian mentors [11:28] btw, the package does appear in http://revu.ubuntuwire.com/?archived=true, but is it enough ? [11:30] paissad: Unarchived. [11:31] jpds, i should unarchive it ? .... that's what you mean ? [11:31] paissad: No; that's what I've done and it's now on the front page. [11:32] oh ok thx then :) [11:33] Could someone take a few minutes to review http://revu.ubuntuwire.com/details.py?upid=7680 please? [11:43] bdrung: ping [11:43] ari-tczew: pong [11:44] bdrung: is there a different process between fake sync universe and fake sync main? [11:44] no, there shouldn't [11:44] bdrung: so you can't doing fake sync [11:45] bdrung: look @ bug 517297 [11:45] why? [11:45] Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Fix released] https://launchpad.net/bugs/517297 [11:47] ari-tczew: thinking about it, the ubuntu diff is better. [11:48] bdrung: look too @ http://pastebin.com/d32050806 [11:50] bdrung: so, do you will review again my debdiff in bug 521337 ? [11:50] Launchpad bug 521337 in pyclamd "Fake sync python-pyclamd 0.1.1-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/521337 [11:50] ari-tczew: yes, will do your fakesync [11:51] bdrung: thanks :-) [11:53] ari-tczew: i will drop the 0.1.1-0ubuntu1 changelog entry [11:54] bdrung: hmmm, main sponsors didn't drop ubuntu's changelog ;-> [11:57] ari-tczew: let's see if i can find a common practice for it === Knightlust is now known as Igorots [11:59] bdrung: have debian/changelog structure like in merges, I guess [11:59] ari-tczew: a real sync would drop the ubuntu changes, too. [12:01] bdrung: heh, dispute quesion [12:01] maybe other MOTU give opinion [12:03] would be nice to have a page on wiki.ubuntu.com about fake syncs [12:04] ari-tczew: seconded. found this: https://wiki.ubuntu.com/PackagingGuide/Wishlist?highlight=%28fakesync%29 [12:05] but nothing useful [12:05] bdrung: sure, need to correct HowTo [12:06] ping: Kmos [12:06] ari-tczew: maybe i should improve my fakesync script and promote it into ubuntu-dev-tools [12:07] bdrung: can you show me code of this script? [12:08] yes [12:09] ari-tczew: http://paste.debian.net/59720/ [12:10] ari-tczew: it works on bug reports [12:14] brung: is your script updated to method which we are explained today on IRC? [12:17] s/brung/bdrung [12:19] ari-tczew: it drops the ubuntu changes. what it does: it grabs the information from the bug, downloads debians and ubuntus version, extract debians package, replace the orig.tar from debians by ubuntus, add a changelog entry, builds the package, uploads it [12:21] bdrung: "it grabs the information from the bug" for what? [12:21] ari-tczew: package name, version, bug number (for changelog) [12:22] ari-tczew: it's for the sponsoring [12:25] bdrung: I'll test your script [12:25] ari-tczew: you have to tweak it (because it assumes that you can upload the package) [12:26] ari-tczew: it's quick & dirty [12:27] bdrung: remove line 149-211 ? [12:28] ari-tczew: 139 - 156 [12:33] bdrung: where is the debdiff? [12:33] /tmp/fakesync [12:34] ari-tczew: it creates the debian -> ubuntu diff [12:37] bdrung: still not useful [12:37] ari-tczew: you can tweak it [12:40] bdrung: the bug is in debian/changelog management, right? [12:41] ari-tczew: yes, if you call it a bug [12:42] s/bug/issue [12:45] <^arky^> Hi, Can any MOTU look at a11y bug 510182 please? [12:45] Launchpad bug 510182 in espeak "New upstream version available" [Undecided,New] https://launchpad.net/bugs/510182 [12:47] may i talk about ppa launchpad ? ... i want to make my package temporary available waiting for it to be advocated, but i don't know how to upload the .deb file [12:47] http://ppa.launchpad.net/paissad/pms-linux/ubuntu/pool/main/p/pms-linux/ [12:47] i just have the sourc [12:47] source* [12:48] the binaries get auto-compiled I thought? [12:48] it might take a while [12:48] azeem, so, i have to wait ? [12:48] it not my duty ? [12:48] it's* [12:49] ^arky^: could you give a link to source tarball? [12:50] ^arky^: ok, founded in bug [12:55] <^arky^> ari-tczew: http://espeak.sourceforge.net/test/latest.html [12:56] bdrung: hmmm, I think that we need to improve in script merging debian/changelog. do you have any other ideas? [12:56] <^arky^> ari-tczew: can you please let me know how you can package this newer version as well [12:57] ari-tczew: rewrite from scratch ;) [12:59] ^arky^: the easiest way is get latest tarball and adjust debian/ directory [12:59] bdrung: scratch is merging 2 files? [12:59] <^arky^> ari-tczew: thank you [13:01] ari-tczew: yes, we need a merge for debian/changelog [13:24] bdrung: can you tweak script? [13:24] ari-tczew: currently i have not the time for it. [13:42] bdrung: I can't code in python, how can we merge 2 files? [13:43] ari-tczew: dunno. you have to call other programs (diff + patch?). [13:49] bdrung: ok, I'm going to do other fake syncs manually, no waste time for noob-scripting. Benjamin, do you will work on bug 511448 or can I done this? [13:49] Launchpad bug 511448 in libxml-security-java "Fake sync libxml-security-java 1.4.3-2 (main) from Debian testing (main)" [Undecided,Triaged] https://launchpad.net/bugs/511448 [13:50] ari-tczew: you can take this [14:05] Could someone please review / sponsor http://revu.ubuntuwire.com/p/turnin-ng (simple python application, both turnin-ng_1.0.1-0ubuntu1_source.changes and turnin-ng_1.0.1-0ubuntu1_i386.changes are lintian -IivmE --pedantic clean) [14:07] is there some team interested in ps3/xbox, etc... in Debian/Ubuntu ? [14:17] can someone sponsor take a look @ bug 521312, I'm not sure whether requestsync correct recognized component (main/universe) [14:17] Launchpad bug 521312 in geronimo-j2ee-connector-1.5-spec "Sync geronimo-j2ee-connector-1.5-spec 2.0.0-1 (main) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/521312 [14:35] ari-tczew: requestsync got the component right, it got promoted during karmic to main (after the last upload) === asac_ is now known as asac [15:16] which of theses 2 version is newer ? ... 1.20+svn386-1 and 1.20.392-1 [15:17] i expected 1.20.392-1 to be newer [15:17] +1 1.20.392 [15:17] paissad, 1.20.392-1 === asac_ is now known as asac [15:36] i've 1st built my package arch dependent ... so i get amd64.deb & i386.deb .... but now i 've built it for all arch, i obtained all.deb .... and i put i in my personal repository, but the matter is that apt-cache policy does not see the new package ( all.deb) ... is it because i installed 1st i386.deb package ? [15:36] how users can update their package then ? [15:41] paissad: You probably need to fiddle with the Packages and Release files in your personal repository. I don't know of any good channel to get support for that. [15:41] paissad: Also, you may find `dpkg --compare-versions ...` to be a very useful command. [15:43] ok [15:43] bdrung: why you didn't include update-maintainer changes? [15:44] in fake syncs [15:44] dholbach explain, that this is needed [15:45] ari-tczew: then i have to talk to him [15:46] The reason we do update-maintainer for fakesyncs is that because the tarballs differ, we can't know that a bug isn't caused by something there. [15:46] fake-syncs are usually uploaded as -XbuildY and don't need a maintainer change [15:47] geser: That would be bad, because it causes a sync failure, and ends up with archive admins either having to fiddle, or update the blacklist. [15:47] fakesyncs should *really* get an ubnutu version and use update-maintainer. [15:47] when did this change? [15:47] I didn't think it had. [15:49] we have 5 people and 6 opinions. we need a wiki page for fake syncs [15:50] persia: see e.g. bug #366812 or http://changelogs.ubuntu.com/changelogs/pool/universe/p/postgresql-8.0/postgresql-8.0_8.0.7-2build1/changelog for the usage of -XbuildY (I could google for some more if needed) [15:50] Launchpad bug 366812 in nautilus-image-converter "Fake-sync nautilus-image-converter from debian experimental" [Wishlist,Fix released] https://launchpad.net/bugs/366812 [15:51] geser: I suspect there are many examples. I just think they are all wrong. [15:52] then we should get it documented somewhere properly (and let all devs know about it) [15:52] Makes sense. [15:52] geser: my words [15:52] * persia does a full-text search on the wiki for fakesync [15:52] persia: there is nothing [15:52] bdrung: in a full-text search? Should be at least something. [15:53] Titile-search, I agree. [15:53] persia: some results are there, but no description how a fake sync should be done. [15:53] titile ;) [15:54] bdrung: Understood. I'm planning to put up a recipe, but just want to make sure I've gotten some good hints first. [15:54] https://wiki.ubuntu.com/PackagingGuide/Wishlist is a good hit, for example :) [15:55] (not that I agree with that description) [15:56] But https://wiki.ubuntu.com/FoundationsTeam/Meetings/2008/1119 seems to indicate that we have competing meanings of "fakesync" :( [15:57] So, before I document anything: let's agree on terminology. I assert that a "fakesync" is when we apply Debian packaging to an Ubuntu tarball. I'd like suggestions on a term for when we "sync" from Debian VCS (I would have thought it just a regular Ubuntu upload) [16:01] for me fake-sync is: Ubuntu .orig.tar.gz + Debian .diff.gz [16:01] Excellent. So do we need a term for the other class mentioned in that foundations meeting? === Igorots is now known as Knightlust [16:04] geser: Ubuntu tarball + Debian .diff.gz + dch -i (fake sync due to mismatching tarball) [16:05] ari-tczew: right, and (depending on the results of this discussion) potentially a maintainer change. [16:05] ari-tczew: But that's too small a chance to matter. [16:07] persia: it depends on the used version. ubuntu1 needs update-maintainer, build1 not [16:09] persia, geser, bdrung: http://pastebin.com/d32050806 [16:09] bdrung: Why? [16:09] look @ line 22. [16:10] persia: with ubuntu1 "debuild -S" will fail in most cases [16:10] ari-tczew: You cite someone else's opinion, which may be useful, but please argue your own case. [16:10] bdrung: I think that's a tools issue. [16:11] https://wiki.ubuntu.com/DebianMaintainerField says "If a source package is modified relative to Debian (this can be determined automatically by examining the version number), its Maintainer field should be updated either as above, or with a more appropriate Ubuntu contact if one exists" [16:11] I read that to require use of update-maintainer for all changes of any sort. [16:13] is it a change if we use a different .orig.tar.gz which is identical content-wise (diff is emtpy) but not bit-identical? [16:13] geser: I'd say no, but I'd say that adding a changelog entry makes it no longer bit-identical. [16:14] in case of doubt we should change the maintainer field [16:15] with the same logic we should also version no-change rebuilds -XubuntuY instead of -XbuildY [16:15] Why? [16:16] because we add a changelog entry for the rebuild? [16:16] I agrue that -XbuildY vs. -XubuntuY is *entirely* a way we can provide hints as to whether to autosync next time, and should have nothing to do with the Maintainer field. [16:16] Hrm. [16:17] If I stand on policy, I'll argue that rebuilds should also get a maintainer change, but that just adds noise to the patch. I'm not sure this policy wouldn't benefit from deeper review. [16:18] looking at https://wiki.ubuntu.com/DebianMaintainerField we have to update the maintainer for rebuilds too [16:19] That's my interpretation as well. [16:19] the binary debs get always the Maintainer field overwritten [16:19] Right. [16:19] The question is just about how we deal with source changes. [16:20] (or rather, what level of source change constitutes a "change") [16:21] * persia is getting the sinking feeling that this may end up being something to present to the TB for review/discussion [16:21] persia: respecting the vote, my opinion is that every change (including changelog modification) is a change [16:21] IMHO only a changelog entry shouldn't count as "change" as we don't have any other option for e.g. no-change rebuilds [16:22] * persia can see the strengths of both of those arguments, and doesn't have a strong opinion between them [16:22] let the TB decide [16:22] bdrung: Are you up for taking this to the TB for clarification? [16:23] persia: i would prefer if someone else can do it [16:24] heh. [16:24] * persia has some outstanding actions for the TB and would prefer not to bring new issues until those are resolved [16:26] * bdrung has one outstanding action for the TB, too. [16:27] geser: ari-tczew : either of you have a sufficient absence of overhanging guilt ? [16:29] OK. Fine, let's set this part aside for now, until we get a volunteer. [16:29] So, a changelog-only change may or may not require update-maintainer. [16:29] Next: what revision should we use for fakesyncs? [16:30] persia: ubuntu1 will definitively require update-maintainer for not-@ubuntu.com maintainer. [16:31] bdrung: But again, that might be a bug in the tools. [16:32] persia: ubuntu1 indicates a ubuntu change. so i won't call it a bug. [16:32] bdrung: And build1 doesn't indicate an Ubuntu change? [16:33] persia: indicates a no-source-change only-adding-a-changelog-entry build [16:34]