| dupondje | geser: is there a special command to generate a merge bugreport ? | 00:00 |
|---|---|---|
| geser | dupondje: no | 00:00 |
| geser | 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:01 |
| ryanakca | 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:02 |
| lfaraone | geser: oops, thanks. | 00:04 |
| geser | ryanakca: does it only work with python 2.6? | 00:05 |
| ryanakca | geser: No, python2.5 as well | 00:05 |
| ryanakca | geser: switch to python (>= 2.5) in control and 2.5-2.6 in pyversions ? | 00:06 |
| geser | ryanakca: then 2.5- in debian/pyversions would be better (if I remember the syntax correctly) | 00:06 |
| ryanakca | geser: Wouldn't that also let 3.x in? | 00:06 |
| ScottK | ryanakca: No | 00:06 |
| ryanakca | or no, nevermind, pycompat takes care of that | 00:06 |
| dupondje | geser: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/521217 | 00:07 |
| ubottu | Ubuntu bug 521217 in gnucash "Merge gnucash 2.2.9-3 from debian sid" [Undecided,New] | 00:07 |
| ScottK | There will be a seperate way to specify Python3 versions. | 00:07 |
| ScottK | ryanakca: Also XS-Python-Version is preferred over pyversions. | 00:07 |
| ryanakca | ScottK: OK | 00:07 |
| dupondje | ah damn, forgot to change maintainer ;) | 00:07 |
| geser | ScottK: do you know if we keep python3.0 in the archive for lucid? | 00:08 |
| ScottK | geser: I think not. I think just 3.1. | 00:08 |
| ryanakca | ScottK, geser: done | 00:09 |
| dupondje | fixed :) | 00:10 |
| geser | 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:11 |
| dupondje | geser: so I need to add old ubuntu changelogs ? I checked the patches, and everything got into sid | 00:13 |
| lifeless | dupondje: if everything is in sid, do a sync, not a merge | 00:13 |
| dupondje | 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 |
| dupondje | so its a merge ? | 00:14 |
| lifeless | EPARSE | 00:15 |
| geser | dupondje: sort of, a comment in the bug about your analysis of the ubuntu delta would be good | 00:15 |
| geser | lifeless: all old ubuntu delta got into the Debian package -> sync but the package would FTBFS without a new patch | 00:15 |
| lifeless | ah | 00:16 |
| lifeless | I'd do a sync, let it FTBFS, and then a new ubuntu patch | 00:16 |
| geser | dupondje: and don't forget to subscribe the sponsors-team | 00:16 |
| sistpoty | geser: all fine as expected, now I can just upload, or do I need to bzr push? | 00:16 |
| geser | sistpoty: bzr commit | 00:17 |
| sistpoty | geser: already done that | 00:17 |
| geser | bzr mark-uploaded | 00:17 |
| geser | bzr push lp:ubuntu/mknbi | 00:17 |
| geser | and upload the build package | 00:17 |
| geser | the push will mark the merge-proposal as merged (else I have to update the status myself) | 00:18 |
| geser | 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 |
| sistpoty | geser: ok, done all that, thanks a lot! | 00:19 |
| geser | sistpoty: until we get "BuildFromBranch" into the archive one has to push and upload | 00:19 |
| ari-tczew | sistpoty: hi, are you active on IRC if development cycle going to FFe? | 00:20 |
| sistpoty | (I must admit that that's the most complicated form I've seen so far to review a *simple* debdiff) | 00:20 |
| sistpoty | 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 |
| geser | sistpoty: if would have wanted a simple debdiff, I could have provided it | 00:21 |
| sistpoty | geser: then I wouldn't have learned the bzr magic ;) | 00:21 |
| dupondje | geser: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/521217 => added ubuntu changelogs + more info for the merge | 00:22 |
| ubottu | Ubuntu bug 521217 in gnucash "Merge gnucash 2.2.9-3 from debian sid" [Undecided,New] | 00:22 |
| sistpoty | geser: I think bzr really comes in handy for more complicated things, and you got me curious to find out ;) | 00:22 |
| ari-tczew | geser: wanna sponsor? | 00:23 |
| geser | sistpoty: you now know 2/3 of how to do bzr based merges too :) | 00:23 |
| geser | ari-tczew: sponsor what? | 00:24 |
| lfaraone | 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 |
| sistpoty | 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:24 |
| geser | 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 |
| sistpoty | s/bad/underdocumented/ | 00:25 |
| ari-tczew | geser: sync bug 521220 | 00:25 |
| ubottu | 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:25 |
| sistpoty | 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:26 |
| lifeless | geser: because a) most packages get built more than once anyway, so its not like its a new thing | 00:28 |
| lifeless | geser: and having a smaller more obvious delta against debian helps the next sync/merge cycle. | 00:29 |
| geser | in such a case I wouldn't insist on keeping the old ubuntu changelog entries | 00:29 |
| geser | bug I still would prefer to do 1 upload instead of a sync and patch later | 00:30 |
| dupondje | 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 |
| dupondje | it introduces http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567208 | 00:31 |
| ubottu | Debian bug 567208 in gnucash "Gnucash 2.2.9-3 has no graphing support" [Serious,Open] | 00:31 |
| sistpoty | 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:32 |
| geser | 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:33 |
| dupondje | well now its clear anyway :D | 00:34 |
| sistpoty | 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:34 |
| sistpoty | (that sentence was grammatically wrong) | 00:35 |
| lifeless | 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 |
| lifeless | otherwise it gets larger and larger and harder to tell | 00:35 |
| lifeless | particularly with upstream releases take patches | 00:35 |
| sistpoty | 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:36 |
| sistpoty | 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 |
| sistpoty | lifeless: until I was convinced (maybe with a pointy stick) that there is some value to keep old changelog entries ;) | 00:37 |
| paissad | it seems that the package is ok now , may someone confirms it ? please | 00:39 |
| paissad | http://revu.ubuntuwire.com/p/pms-linux | 00:39 |
| dupondje | nite guys | 00:46 |
| dupondje | thx for assistance :) | 00:46 |
| quentusrex | Anyone able to help debug a package file issue? I have a package that has stopped installing certain files. | 00:47 |
| quentusrex | I have the package freeswitch, and freeswitch-lua | 00:48 |
| quentusrex | 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 |
| quentusrex | I have extracted the f-lua.deb with dpkg-deb --extract... | 00:48 |
| quentusrex | and the files are there | 00:49 |
| quentusrex | they jsut aren't ever copied to the location... | 00:49 |
| quentusrex | it's driving me insane... I have no idea what could be going wrong... | 00:49 |
| quentusrex | lifeless, sistpoty ^ | 00:51 |
| sistpoty | quentusrex: .la files should generally get removed, let me dig the thread on debian-devel | 00:52 |
| quentusrex | generally yes, but not in this case. | 00:53 |
| quentusrex | but I am looking at the freeswitch.install file and it has a bunch of .so's that are getting installed | 00:53 |
| quentusrex | but the freeswitch-lua.install file has the list of files, but they aren't getting copied. | 00:53 |
| quentusrex | 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:54 |
| sistpoty | 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 |
| quentusrex | I think I found something interesting: chroot-autobuild/build/buildd/freeswitch-lua_1.0.4+repack12-0ubuntu16625M.0~karmic_amd64.deb | 00:57 |
| quentusrex | that step | 00:58 |
| quentusrex | doesn't actually copy files... | 00:58 |
| quentusrex | it doesn't copy the .so's like the other steps do | 00:58 |
| quentusrex | http://launchpadlibrarian.net/39125363/buildlog_ubuntu-karmic-amd64.freeswitch_1.0.4%2Brepack12-0ubuntu16625M.0~karmic_FULLYBUILT.txt.gz | 00:59 |
| quentusrex | you can see if you search for the chroot line in that buildlog | 00:59 |
| quentusrex | just above that maybe 100 lines up | 00:59 |
| quentusrex | it copies .so's | 00:59 |
| quentusrex | but it doesn't for any other package. | 00:59 |
| quentusrex | that's my problem. | 00:59 |
| quentusrex | sistpoty, do you see what I mean? | 01:01 |
| sistpoty | 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 |
| quentusrex | right | 01:01 |
| quentusrex | but in freeswitch-lua_1.0.4+repack12-0ubuntu16625M.0~karmic_amd64.deb there are no .so files | 01:02 |
| quentusrex | nor in -perl, or -spidermonkey | 01:02 |
| quentusrex | etc. | 01:02 |
| quentusrex | when there should be atleast a few in each. | 01:02 |
| iclebyte | 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:02 |
| sistpoty | quentusrex: I'm sorry, but I cannot really help you with ppa-related things. please ask in #launchpad | 01:03 |
| sistpoty | iclebyte: there's no debian/changelog? | 01:03 |
| iclebyte | no.. I'm attempting to build postfix-2.5.1 sources after applying the VDA quota patch. | 01:04 |
| iclebyte | 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:05 |
| sistpoty | ScottK: ^^ reproducible with plain postfix as in the archives | 01:08 |
| * ScottK looks | 01:09 | |
| sistpoty | ScottK: do missing build-depends result in that error? (as I don't have all b-d installed) | 01:09 |
| sistpoty | ScottK: looks like it, sorry for the noise | 01:12 |
| ScottK | Ah. | 01:12 |
| sistpoty | iclebyte: you'll need all build-dependencies installed | 01:12 |
| sistpoty | iclebyte: hence an apt-get build-dep postfix | 01:13 |
| sistpoty | iclebyte: should fix the "problem" | 01:13 |
| ScottK | 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 |
| iclebyte | I already did that... | 01:13 |
| sistpoty | 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:14 |
| ari-tczew | sispoty: can you sponsoring for main? | 01:15 |
| sistpoty | ari-tczew: yes | 01:15 |
| ari-tczew | cool! | 01:16 |
| sistpoty | ari-tczew: as in got a but number? | 01:16 |
| sistpoty | s/but/bug/ | 01:16 |
| ari-tczew | sistpoty: not now, generally I'm going to do a debdiff for some fake syncs | 01:17 |
| iclebyte | 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 |
| iclebyte | 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:17 |
| sistpoty | ari-tczew: ok | 01:18 |
| sistpoty | iclebyte: did you do an apt-get build-dep postfix? | 01:18 |
| iclebyte | i did both. | 01:19 |
| sistpoty | iclebyte: what version of Ubuntu are you running? | 01:20 |
| iclebyte | 8.04-LTS the server one. | 01:20 |
| sistpoty | iclebyte: let me try to reproduce the problem (takes some time, I'll need to create an 8.04 chroot first) | 01:22 |
| iclebyte | sistpoty, thanks very much! | 01:24 |
| * iclebyte might make a cup of tea and hang around a bit =) | 01:24 | |
| iclebyte | sistpoty, I've fixed it! | 01:31 |
| iclebyte | 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:32 |
| iclebyte | (that's my assumption as to how it works anyway) | 01:33 |
| sistpoty | iclebyte: great | 01:34 |
| iclebyte | thankyou for your help though, it is much appreciated | 01:35 |
| sistpoty | 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 |
| ubottu | Launchpad bug 512358 in e2fsprogs "FTBFS: missing html files" [Undecided,New] https://launchpad.net/bugs/512358 | 02:05 |
| * sistpoty heads to bed now, gn8 everyon | 02:09 | |
| sistpoty | +e | 02:09 |
| paissad | i see my package now in the site, but is it in the right place in order to get advocated ? | 02:35 |
| paissad | http://revu.ubuntuwire.com/p/pms-linux | 02:35 |
| paissad | is there something else to do ? | 02:36 |
| wrapster | I want to build a pkg so I un-tarred the source put it into a dir called <my-deb-pkg-version1> then entered that dir and did a dh_make | 02:53 |
| wrapster | but it fails saying.. cannot understand the dir name | 02:54 |
| lfaraone | 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? | 03:46 |
| doctormo | We're looking for advice on bug 521263 can anyone lend a hand? | 04:22 |
| ubottu | Launchpad bug 521263 in groundcontrol "GC postinst should not modify configuration files owned by other packages" [Undecided,New] https://launchpad.net/bugs/521263 | 04:22 |
| superm1 | <3> is the most favorable solution | 04:27 |
| superm1 | although you'll probably want to raise that with the freedesktop folks first | 04:28 |
| lfaraone | doctormo: see DPM §10.7.4: http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4 | 04:29 |
| lfaraone | superm1: which would be doable in time for FF? :) | 04:29 |
| superm1 | lfaraone, well lob an email over to their mailing list and see how they feel about adding another directory to the spec | 04:30 |
| superm1 | 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:30 |
| superm1 | which should be achievable in time for FF | 04:31 |
| superm1 | and if not, I don't see why an FFe couldn't be done for something like this | 04:31 |
| lfaraone | superm1: well, groundcontrol isn't in Ubuntu yet. | 04:31 |
| superm1 | lfaraone, that's okay. | 04:36 |
| superm1 | lfaraone, the other thing i'd propose is maybe just choosing one of the existing xdg directories and making a subdirectory | 04:37 |
| lfaraone | doctormo: is that an acceptable alternative? | 04:37 |
| superm1 | like $DOCUMENTS/Projects perhaps | 04:37 |
| lfaraone | doctormo: (assuming XDG says "no") | 04:37 |
| doctormo | 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 |
| lfaraone | doctormo: I mean, can't we have some better functionality to control whether groundcontrol is enabled or not than XDG settings? :) | 04:43 |
| doctormo | You mean, display the projects banner on every nautilus folder | 04:44 |
| lfaraone | doctormo: no, default to something like $DOCUMENTS/Projects, and let it be configurable via say .config/groundcontrol/blah.ini | 04:45 |
| doctormo | bleh, configs for directories, it's like they want to make this hard | 04:45 |
| doctormo | What would create that folder | 04:46 |
| doctormo | Why would that be default | 04:46 |
| doctormo | That's not even how I organise my projects | 04:46 |
| doctormo | projects aren't documents | 04:46 |
| lfaraone | doctormo: you're right. we could just ignore the XDG spec entirely and write to $HOME/Projects. | 04:48 |
| kklimonda | 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:52 |
| kklimonda | 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:53 |
| doctormo | lfaraone: The cheese program creates a directory every time it runs, it's really annoying | 04:57 |
| doctormo | and for many months I never knew why | 04:57 |
| doctormo | It turns out it was because the XDG video directory pointed to my home folder | 04:57 |
| doctormo | And it would magically make a directory Webcam every load | 04:58 |
| doctormo | That's also a really bad idea | 04:58 |
| doctormo | 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. | 04:59 |
| maitraya | I am a high school student. What are the qualifications I require to be a MOTU member? | 06:59 |
| maitraya | [12:29] <maitraya> I am a high school student. What are the qualifications I require to be a MOTU member? Please help | 07:03 |
| kklimonda | ma10, https://wiki.ubuntu.com/MOTU#So%20you%20want%20to%20be%20a%20MOTU? | 07:03 |
| kklimonda | ai | 07:03 |
| kklimonda | maitraya, https://wiki.ubuntu.com/MOTU#So%20you%20want%20to%20be%20a%20MOTU? | 07:03 |
| maitraya | thanks | 07:04 |
| fabrice_sp | maitraya, also see the topic (https://wiki.ubuntu.com/MOTU/Contributing) | 07:06 |
| ari-tczew | would be nice if everybody will update its merges before FFe ! | 09:53 |
| hyperair | 'its merges' <-- referring to what? | 09:53 |
| ari-tczew | 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:55 |
| hyperair | what do you mean by "not updated"? | 09:58 |
| hyperair | as in not uploaded yet? | 09:58 |
| hyperair | or there are new merges to be done? | 09:58 |
| hyperair | or what? | 09:58 |
| ari-tczew | new merges | 09:59 |
| ari-tczew | of course | 09:59 |
| hyperair | ah | 09:59 |
| dupondje | I uploaded one, waiting to be accepted :P | 10:01 |
| hyperair | quadrispro: regarding codelite, are you interested in taking over maintainership of it? | 10:07 |
| hyperair | quadrispro: i noticed you uploaded a new upstream release of codelite recently. | 10:07 |
| quadrispro | hi hyperair! yep, that release fixes a lot of issues | 10:08 |
| hyperair | quadrispro: cool. in that case, could you keep the git packaging repository up to date, or move the packaging elsewhere? | 10:10 |
| quadrispro | hyperair, ah! you're right | 10:10 |
| quadrispro | no, I'll update the git repo | 10:10 |
| hyperair | i've already updated it on your behalf =) | 10:10 |
| quadrispro | I didn't notice it before | 10:10 |
| hyperair | =) | 10:11 |
| quadrispro | excellent :) | 10:11 |
| hyperair | 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:12 |
| ari-tczew | is it available to do a merge past FFe? | 10:13 |
| hyperair | quadrispro: you might also like trying to get codelite into debian, if you know someone who would upload it. | 10:14 |
| asbin | 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:17 |
| geser | ari-tczew: yes, after FF you can do merges too, you just might need a FF exception when merging a new upstream version | 10:18 |
| ari-tczew | geser: but if there are not new upstream version, just new release Debian version: do I should give a FFe reason? | 10:19 |
| geser | no, but think if we need those changes before merging | 10:22 |
| gusnan | 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:37 |
| quadrispro | hyperair, ok | 10:42 |
| paissad | guys, my package does no appear in new packages ! ... in the http://revu.ubuntuwire.com/ site ... the package is pms-linux ^^ | 11:25 |
| ari-tczew | why people uploading new packages to REVU instead Debian Mentors? | 11:26 |
| paissad | oh | 11:27 |
| geser | they still have hope to get the package faster through REVU than Debian mentors | 11:28 |
| paissad | btw, the package does appear in http://revu.ubuntuwire.com/?archived=true, but is it enough ? | 11:28 |
| jpds | paissad: Unarchived. | 11:30 |
| paissad | jpds, i should unarchive it ? .... that's what you mean ? | 11:31 |
| jpds | paissad: No; that's what I've done and it's now on the front page. | 11:31 |
| paissad | oh ok thx then :) | 11:32 |
| oojah | Could someone take a few minutes to review http://revu.ubuntuwire.com/details.py?upid=7680 please? | 11:33 |
| ari-tczew | bdrung: ping | 11:43 |
| bdrung | ari-tczew: pong | 11:43 |
| ari-tczew | bdrung: is there a different process between fake sync universe and fake sync main? | 11:44 |
| bdrung | no, there shouldn't | 11:44 |
| ari-tczew | bdrung: so you can't doing fake sync | 11:44 |
| ari-tczew | bdrung: look @ bug 517297 | 11:45 |
| bdrung | why? | 11:45 |
| ubottu | 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:45 |
| bdrung | ari-tczew: thinking about it, the ubuntu diff is better. | 11:47 |
| ari-tczew | bdrung: look too @ http://pastebin.com/d32050806 | 11:48 |
| ari-tczew | bdrung: so, do you will review again my debdiff in bug 521337 ? | 11:50 |
| ubottu | 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 |
| bdrung | ari-tczew: yes, will do your fakesync | 11:50 |
| ari-tczew | bdrung: thanks :-) | 11:51 |
| bdrung | ari-tczew: i will drop the 0.1.1-0ubuntu1 changelog entry | 11:53 |
| ari-tczew | bdrung: hmmm, main sponsors didn't drop ubuntu's changelog ;-> | 11:54 |
| bdrung | ari-tczew: let's see if i can find a common practice for it | 11:57 |
| === Knightlust is now known as Igorots | ||
| ari-tczew | bdrung: have debian/changelog structure like in merges, I guess | 11:59 |
| bdrung | ari-tczew: a real sync would drop the ubuntu changes, too. | 11:59 |
| ari-tczew | bdrung: heh, dispute quesion | 12:01 |
| ari-tczew | maybe other MOTU give opinion | 12:01 |
| ari-tczew | would be nice to have a page on wiki.ubuntu.com about fake syncs | 12:03 |
| bdrung | ari-tczew: seconded. found this: https://wiki.ubuntu.com/PackagingGuide/Wishlist?highlight=%28fakesync%29 | 12:04 |
| bdrung | but nothing useful | 12:05 |
| ari-tczew | bdrung: sure, need to correct HowTo | 12:05 |
| ari-tczew | ping: Kmos | 12:06 |
| bdrung | ari-tczew: maybe i should improve my fakesync script and promote it into ubuntu-dev-tools | 12:06 |
| ari-tczew | bdrung: can you show me code of this script? | 12:07 |
| bdrung | yes | 12:08 |
| bdrung | ari-tczew: http://paste.debian.net/59720/ | 12:09 |
| bdrung | ari-tczew: it works on bug reports | 12:10 |
| ari-tczew | brung: is your script updated to method which we are explained today on IRC? | 12:14 |
| ari-tczew | s/brung/bdrung | 12:17 |
| bdrung | 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:19 |
| ari-tczew | bdrung: "it grabs the information from the bug" for what? | 12:21 |
| bdrung | ari-tczew: package name, version, bug number (for changelog) | 12:21 |
| bdrung | ari-tczew: it's for the sponsoring | 12:22 |
| ari-tczew | bdrung: I'll test your script | 12:25 |
| bdrung | ari-tczew: you have to tweak it (because it assumes that you can upload the package) | 12:25 |
| bdrung | ari-tczew: it's quick & dirty | 12:26 |
| ari-tczew | bdrung: remove line 149-211 ? | 12:27 |
| bdrung | ari-tczew: 139 - 156 | 12:28 |
| ari-tczew | bdrung: where is the debdiff? | 12:33 |
| bdrung | /tmp/fakesync | 12:33 |
| bdrung | ari-tczew: it creates the debian -> ubuntu diff | 12:34 |
| ari-tczew | bdrung: still not useful | 12:37 |
| bdrung | ari-tczew: you can tweak it | 12:37 |
| ari-tczew | bdrung: the bug is in debian/changelog management, right? | 12:40 |
| bdrung | ari-tczew: yes, if you call it a bug | 12:41 |
| ari-tczew | s/bug/issue | 12:42 |
| ^arky^ | Hi, Can any MOTU look at a11y bug 510182 please? | 12:45 |
| ubottu | Launchpad bug 510182 in espeak "New upstream version available" [Undecided,New] https://launchpad.net/bugs/510182 | 12:45 |
| paissad | 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 |
| paissad | http://ppa.launchpad.net/paissad/pms-linux/ubuntu/pool/main/p/pms-linux/ | 12:47 |
| paissad | i just have the sourc | 12:47 |
| paissad | source* | 12:47 |
| azeem | the binaries get auto-compiled I thought? | 12:48 |
| azeem | it might take a while | 12:48 |
| paissad | azeem, so, i have to wait ? | 12:48 |
| paissad | it not my duty ? | 12:48 |
| paissad | it's* | 12:48 |
| ari-tczew | ^arky^: could you give a link to source tarball? | 12:49 |
| ari-tczew | ^arky^: ok, founded in bug | 12:50 |
| ^arky^ | ari-tczew: http://espeak.sourceforge.net/test/latest.html | 12:55 |
| ari-tczew | 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:56 |
| bdrung | ari-tczew: rewrite from scratch ;) | 12:57 |
| ari-tczew | ^arky^: the easiest way is get latest tarball and adjust debian/ directory | 12:59 |
| ari-tczew | bdrung: scratch is merging 2 files? | 12:59 |
| ^arky^ | ari-tczew: thank you | 12:59 |
| bdrung | ari-tczew: yes, we need a merge for debian/changelog | 13:01 |
| ari-tczew | bdrung: can you tweak script? | 13:24 |
| bdrung | ari-tczew: currently i have not the time for it. | 13:24 |
| ari-tczew | bdrung: I can't code in python, how can we merge 2 files? | 13:42 |
| bdrung | ari-tczew: dunno. you have to call other programs (diff + patch?). | 13:43 |
| ari-tczew | 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 |
| ubottu | 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:49 |
| bdrung | ari-tczew: you can take this | 13:50 |
| ryanakca | 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:05 |
| paissad | is there some team interested in ps3/xbox, etc... in Debian/Ubuntu ? | 14:07 |
| ari-tczew | can someone sponsor take a look @ bug 521312, I'm not sure whether requestsync correct recognized component (main/universe) | 14:17 |
| ubottu | 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:17 |
| geser | ari-tczew: requestsync got the component right, it got promoted during karmic to main (after the last upload) | 14:35 |
| === asac_ is now known as asac | ||
| paissad | which of theses 2 version is newer ? ... 1.20+svn386-1 and 1.20.392-1 | 15:16 |
| paissad | i expected 1.20.392-1 to be newer | 15:17 |
| ari-tczew | +1 1.20.392 | 15:17 |
| BlackZ | paissad, 1.20.392-1 | 15:17 |
| === asac_ is now known as asac | ||
| paissad | 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 |
| paissad | how users can update their package then ? | 15:36 |
| persia | 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 |
| persia | paissad: Also, you may find `dpkg --compare-versions ...` to be a very useful command. | 15:41 |
| paissad | ok | 15:43 |
| ari-tczew | bdrung: why you didn't include update-maintainer changes? | 15:43 |
| ari-tczew | in fake syncs | 15:44 |
| ari-tczew | dholbach explain, that this is needed | 15:44 |
| bdrung | ari-tczew: then i have to talk to him | 15:45 |
| persia | 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 |
| geser | fake-syncs are usually uploaded as -XbuildY and don't need a maintainer change | 15:46 |
| persia | 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 |
| persia | fakesyncs should *really* get an ubnutu version and use update-maintainer. | 15:47 |
| geser | when did this change? | 15:47 |
| persia | I didn't think it had. | 15:47 |
| bdrung | we have 5 people and 6 opinions. we need a wiki page for fake syncs | 15:49 |
| geser | 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 |
| ubottu | Launchpad bug 366812 in nautilus-image-converter "Fake-sync nautilus-image-converter from debian experimental" [Wishlist,Fix released] https://launchpad.net/bugs/366812 | 15:50 |
| persia | geser: I suspect there are many examples. I just think they are all wrong. | 15:51 |
| geser | then we should get it documented somewhere properly (and let all devs know about it) | 15:52 |
| persia | Makes sense. | 15:52 |
| bdrung | geser: my words | 15:52 |
| * persia does a full-text search on the wiki for fakesync | 15:52 | |
| bdrung | persia: there is nothing | 15:52 |
| persia | bdrung: in a full-text search? Should be at least something. | 15:52 |
| persia | Titile-search, I agree. | 15:53 |
| bdrung | persia: some results are there, but no description how a fake sync should be done. | 15:53 |
| bdrung | titile ;) | 15:53 |
| persia | 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 |
| persia | https://wiki.ubuntu.com/PackagingGuide/Wishlist is a good hit, for example :) | 15:54 |
| persia | (not that I agree with that description) | 15:55 |
| persia | But https://wiki.ubuntu.com/FoundationsTeam/Meetings/2008/1119 seems to indicate that we have competing meanings of "fakesync" :( | 15:56 |
| persia | 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) | 15:57 |
| geser | for me fake-sync is: Ubuntu .orig.tar.gz + Debian .diff.gz | 16:01 |
| persia | Excellent. So do we need a term for the other class mentioned in that foundations meeting? | 16:01 |
| === Igorots is now known as Knightlust | ||
| ari-tczew | geser: Ubuntu tarball + Debian .diff.gz + dch -i (fake sync due to mismatching tarball) | 16:04 |
| persia | ari-tczew: right, and (depending on the results of this discussion) potentially a maintainer change. | 16:05 |
| persia | ari-tczew: But that's too small a chance to matter. | 16:05 |
| bdrung | persia: it depends on the used version. ubuntu1 needs update-maintainer, build1 not | 16:07 |
| ari-tczew | persia, geser, bdrung: http://pastebin.com/d32050806 | 16:09 |
| persia | bdrung: Why? | 16:09 |
| ari-tczew | look @ line 22. | 16:09 |
| bdrung | persia: with ubuntu1 "debuild -S" will fail in most cases | 16:10 |
| persia | ari-tczew: You cite someone else's opinion, which may be useful, but please argue your own case. | 16:10 |
| persia | bdrung: I think that's a tools issue. | 16:10 |
| persia | 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 |
| persia | I read that to require use of update-maintainer for all changes of any sort. | 16:11 |
| geser | 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 |
| persia | geser: I'd say no, but I'd say that adding a changelog entry makes it no longer bit-identical. | 16:13 |
| bdrung | in case of doubt we should change the maintainer field | 16:14 |
| geser | with the same logic we should also version no-change rebuilds -XubuntuY instead of -XbuildY | 16:15 |
| persia | Why? | 16:15 |
| geser | because we add a changelog entry for the rebuild? | 16:16 |
| persia | 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 |
| persia | Hrm. | 16:16 |
| persia | 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:17 |
| bdrung | looking at https://wiki.ubuntu.com/DebianMaintainerField we have to update the maintainer for rebuilds too | 16:18 |
| persia | That's my interpretation as well. | 16:19 |
| geser | the binary debs get always the Maintainer field overwritten | 16:19 |
| persia | Right. | 16:19 |
| persia | The question is just about how we deal with source changes. | 16:19 |
| persia | (or rather, what level of source change constitutes a "change") | 16:20 |
| * persia is getting the sinking feeling that this may end up being something to present to the TB for review/discussion | 16:21 | |
| bdrung | persia: respecting the vote, my opinion is that every change (including changelog modification) is a change | 16:21 |
| geser | 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:21 |
| * persia can see the strengths of both of those arguments, and doesn't have a strong opinion between them | 16:22 | |
| bdrung | let the TB decide | 16:22 |
| persia | bdrung: Are you up for taking this to the TB for clarification? | 16:22 |
| bdrung | persia: i would prefer if someone else can do it | 16:23 |
| persia | heh. | 16:24 |
| * persia has some outstanding actions for the TB and would prefer not to bring new issues until those are resolved | 16:24 | |
| * bdrung has one outstanding action for the TB, too. | 16:26 | |
| persia | geser: ari-tczew : either of you have a sufficient absence of overhanging guilt ? | 16:27 |
| persia | OK. Fine, let's set this part aside for now, until we get a volunteer. | 16:29 |
| persia | So, a changelog-only change may or may not require update-maintainer. | 16:29 |
| persia | Next: what revision should we use for fakesyncs? | 16:29 |
| bdrung | persia: ubuntu1 will definitively require update-maintainer for not-@ubuntu.com maintainer. | 16:30 |
| persia | bdrung: But again, that might be a bug in the tools. | 16:31 |
| bdrung | persia: ubuntu1 indicates a ubuntu change. so i won't call it a bug. | 16:32 |
| persia | bdrung: And build1 doesn't indicate an Ubuntu change? | 16:32 |
| bdrung | persia: indicates a no-source-change only-adding-a-changelog-entry build | 16:33 |
| persia | But is this a change? You argued it was before. | 16:34 |
| ari-tczew | persia: +1 for buildX => debian/{changelog;control} | 16:35 |
| bdrung | persia: do we have a rebuild policy? | 16:37 |
| persia | Not a formal one, to my understanding. | 16:37 |
| bdrung | persia: i change my reasoning: buildX indicated that we can sync from Debian | 16:41 |
| persia | That's been my interpretation. | 16:41 |
| persia | geser: What do you think? | 16:41 |
| geser | mine too | 16:43 |
| persia | Excellent. | 16:44 |
| geser | and don't the archive admin scripts handle -XbuildY that way (auto-sync)? | 16:44 |
| persia | As far as I know,they do. I know MoM does. | 16:44 |
| persia | So, the only bit left is what to do with differing orig.tar.gz files. Since these can't sync, I argue that -XbuildY is incorrect. | 16:45 |
| persia | (or may not be able to sync: we don't know the version of the next Debian upload) | 16:45 |
| kamalmostafa | I'm looking for someone with an "Intel(R) Core(TM)2 Duo CPU P9500" to try the 10-line program in bug 518314 -- I cannot reproduce the reported problem on a similar Core2 Quad. (Or a redirect to a more appropriate channel to ask). | 16:48 |
| ubottu | Launchpad bug 518314 in eglibc "strcmp crashes" [Undecided,New] https://launchpad.net/bugs/518314 | 16:48 |
| ari-tczew | persia: why -XbuildY is incorrect? | 16:49 |
| persia | ari-tczew: My contention is that if we use -XbuildY to indicate that it is safe to sync the package in the future, we cannot use it for fakesyncs because if there is not a new upstream version, we will not be able to sync in the future. | 16:50 |
| geser | persia: so you propose to use something like -XfakesyncY for fakesyncs? | 16:55 |
| sebner | geser: we used ubuntu1 for fakesycns why not keep it? | 16:55 |
| geser | to not overload the meaning of -XubuntuY | 16:57 |
| ari-tczew | no, ubuntu1 sucks for fakesyncs. If we have XbuildY, Debian will get new upstream version, then autosync will replace ubuntu's version with Debian's | 16:57 |
| geser | sebner: I use -XbuildY for fakesyncs and there doesn't seem to be a clear document what to use | 16:57 |
| persia | ari-tczew: That fails if Debian uploads bugfixes that aren't new upsteams. | 16:57 |
| geser | therefore a new suffix | 16:58 |
| ari-tczew | persia: XubuntuY too fails, right? | 16:58 |
| persia | geser: That's one solution. Do you think it's that important to preserve the distinction between fakesyncs and other sorts of Ubuntu modifications? | 16:58 |
| geser | -XbuildY for no-change rebuilds that can be synced on the next Debian revision | 16:58 |
| persia | ari-tczew: Only in a semantic sense. | 16:58 |
| sebner | geser: I always wanted to use XbuildY too but when the next version in Debian isn't new upstream the sync fails so I'm only using XubuntuY | 16:58 |
| geser | -XfakesyncY for fakesync that can be auto-synced on the next upstream version in Debian | 16:58 |
| geser | and -XubuntuY for changes that might need merging | 16:59 |
| sebner | geser: well, you never know if the next version in Debian will be new upstream or not | 16:59 |
| persia | geser: See, one of the reasons I prefer -XubuntuY for fakesyncs is that we *do* need to process them like merges for new Debian revisions. | 16:59 |
| * sebner agrees with persia | 17:00 | |
| l3on | \sh: thanks for uploading ikiwiki. :) | 17:00 |
| geser | persia: even when we know that there are no changes (besides the different md5sum)? | 17:00 |
| persia | geser: Yes, because the merge workflow is nearly identical (although the patch is much smaller) | 17:01 |
| ari-tczew | +1 for still XbuildY or +1 for geser idea | 17:01 |
| persia | ari-tczew: -XbuildY completely fails to work. | 17:01 |
| ari-tczew | ubuntuY too | 17:01 |
| persia | ari-tczew: Why? | 17:01 |
| sebner | It's always the question if your prefer autosync but the possibility to fail OR to not autosync and keep tracking on new upstream versions yourself | 17:02 |
| ari-tczew | if autosync see ubuntu, then giving free to merge | 17:02 |
| ari-tczew | right? | 17:02 |
| persia | autosync fail annoys archive admins. I've had to clear more than one package off the blacklist manually to work around it. | 17:02 |
| persia | ari-tczew: Yes, -XubuntuY provides notification of merge. | 17:02 |
| geser | persia: do you know why this problem wasn't raised earlier? fakesyncs and using -XbuildY for them is nothing new | 17:03 |
| geser | I'd prefer a solution where we don't have to check fakesyncs manually and let the tools sync them on new upstream versions | 17:04 |
| persia | geser: Hrm. I don't. I like the idea of providing enough of a hint that the tools can autosync if appropriate or merge if inappropriate. | 17:05 |
| persia | And -Xfakesync << -XubuntuY which covers that case. I don't think we need a "Y" component for fakesyncs (or they shouldn't be -Xfakesync anymore) | 17:05 |
| geser | persia: perhaps I was a little bit unspecfic: I see now that -XbuildY isn't the right option and -XubuntuY works but doesn't look like the best option either, so a new suffix should be added to handle fakesyncs | 17:08 |
| geser | and right, we should have to fakesync more than once for each X (unless the DD doesn't use a weird revision scheme) | 17:09 |
| persia | Right. | 17:10 |
| ari-tczew | away... | 17:10 |
| persia | So, let me make sure I've got the right notes from the discussion: | 17:10 |
| persia | 1) We don't know if we need update-maintainer for changelog-only fixes | 17:10 |
| geser | correct | 17:10 |
| persia | 2) We want to restrict -XbuildY uploads to rebuilds only: not fakesyncs | 17:10 |
| persia | 3) fakesyncs should use the new -Xfakesync revision | 17:11 |
| geser | correct | 17:11 |
| persia | 4) the tools should be updated to deal with this sanely | 17:11 |
| geser | correct | 17:11 |
| persia | Excellent. | 17:11 |
| persia | bdrung: That works for you? | 17:11 |
| bdrung | persia: yes. | 17:14 |
| * persia will send a mail to ubuntu-devel | 17:14 | |
| bdrung | with Xfakesync the sync tool can automate the syncing (by checking if there is a new upstream release) | 17:14 |
| persia | Right, assuming someone updates the tools. Needs patches to MoM and the archive-admin tools. | 17:15 |
| bdrung | persia: one thing. keeping the ubuntu changelog entries or not? | 17:15 |
| geser | for fake-syncs? no, we only added them because we can't bump the version otherwise | 17:16 |
| persia | That's a tricky one. The argument for keeping them is that it describes the history and rationale of having different orig.tar.gz files. The argument against is that it increases the differences in cases that are essentially syncs. | 17:16 |
| geser | the history is still in LP | 17:17 |
| persia | Good pont. | 17:17 |
| bdrung | +1 for dropping them | 17:17 |
| persia | I'll suggest drop-old-ubuntu-changelog in the mail. | 17:17 |
| geser | and we don't keep the ubuntu changelog entries for sync too (else we would have to merge everytime the old ubuntu changelog entries for every package we touched once) | 17:18 |
| bdrung | geser: once the policy is finished, we can write a fakesync tool | 17:19 |
| persia | bdrung: Feel free to start one now, based on our discussion. The patches for any variance from ML discussion (or TB intervention) is likely to be small. | 17:19 |
| rmunn | Anyone interested in looking at http://revu.ubuntuwire.com/p/python-nltk? One MOTU has already advocated it, just need a second advocate to get it into Lucid. | 17:26 |
| rmunn | Two things that have already been discussed by other reviewers: | 17:28 |
| bdrung | rmunn: "Initial release (Closes LP: #514396)" <-- wrong bug number and remove Closes | 17:29 |
| rmunn | 1) the nltk.jar file contains nothing but code whose source is in the upstream tarball, and there are no licensing problems with redistributing it in the .orig.tar.gz. (And it's deleted in debian/clean so that it can't get into the binary package, thus avoiding any security issues of possible Trojans) | 17:29 |
| persia | rmunn: You may want to put #1 in debian/README.source so you don't have to repeat it so often :) | 17:29 |
| bdrung | rmunn: do you want to bring the package to Debian too? | 17:30 |
| rmunn | bdrung, Huh. I'm certain that was the right bug number when I created it... Weird. | 17:30 |
| rmunn | bdrung, Yes, but I'm not 100% sure of the Debian package-submission process... still reading policy documents, etc. | 17:30 |
| bdrung | rmunn: https://bugs.launchpad.net/openerp-venezuela-localization/+bug/514396 looks wrong ;) | 17:30 |
| ubottu | Ubuntu bug 514396 in openerp-venezuela-localization "Correcciones en Reporte de retencione ISLR para cumplir con las especificaciones legales venezolanas." [Critical,Fix released] | 17:30 |
| rmunn | Oh, it's bug #514936. Oops, typo. | 17:31 |
| ubottu | Launchpad bug 514936 in ubuntu "[needs-packaging] nltk (Natural Language Toolkit)" [Wishlist,In progress] https://launchpad.net/bugs/514936 | 17:31 |
| bdrung | rmunn: first things is to check WNPP and open an ITP | 17:31 |
| rmunn | Drat, that means a new upload and getting sistpoty to re-advocate the package. | 17:31 |
| rmunn | bdrung, The nltk.jar info already is in README.Debian. :-) | 17:32 |
| persia | It doesn't belong in README.Debian, because it's uninteresting to end-users, but that's a very minor nit. | 17:32 |
| persia | no need for a new upload, but if there *is* a new upload, fixing that would be nice :) | 17:33 |
| Rhonda | persia: Am uploading the pgadmin3 package, so aftger next dinstall I guess you can do the snc. | 17:33 |
| Rhonda | persia: And forgive me my typing as the upload is happening right now, I can't type over the lag properly. ;) | 17:34 |
| rmunn | persia, No need for a new upload re: the README.Debian? Or re: the wrong bug number? I think the wrong bug number does require a new upload. | 17:34 |
| bdrung | rmunn: python-nltk source: unused-override build-depends-without-arch-dep python-yaml | 17:34 |
| Rhonda | Or at least fixing the typos isn't working out over the lag. | 17:34 |
| rmunn | bdrung, Already looked at that one & discussed here in #ubuntu-motu a few days ago. It's a false positive. | 17:34 |
| persia | Rhonda: No worries :) | 17:34 |
| rmunn | python-yaml is required for the debian/clean step, so per Debian policy it should be in build-depends, but lintian complains. | 17:35 |
| bdrung | rmunn: don't override false positive. instead open a bug report. in your case this bug was fixed in the latest version. | 17:35 |
| persia | rmunn: wrong bug number would benefit from an upload. Moving discussion of licensing of the .jar file from README.Debian to README.source would be good, but not essential. | 17:35 |
| rmunn | persia, Ah, README.source is where it belongs? Then since I have to do a new upload anyway to get the right bug number, I'll move it. | 17:36 |
| bdrung | rmunn: python-nltk source: out-of-date-standards-version 3.8.3 (current is 3.8.4) | 17:36 |
| bdrung | rmunn: please refer to version copyright file | 17:37 |
| rmunn | I thought 3.8.3 was current when I made the package two weeks ago... Ah, I see, 3.8.4 JUST came out. | 17:37 |
| persia | rmunn: README.Debian should include end-user-interesting information specific to how the upstream source has been packaged, if this changes defaults, etc. README.source should contain developer-interesting information about how the packaging works. | 17:37 |
| * persia looks about for fabricesp and is disappointed | 17:37 | |
| rmunn | bdrung, What do you mean by "please refer to version copyright file"? I don't understand. | 17:38 |
| rmunn | This is my first "real" package (as opposed to training exercises), so all this feedback is GREATLY appreciated, BTW. :-) | 17:38 |
| bdrung | rmunn: debian/copyright: /usr/share/common-licenses/GPL -> /usr/share/common-licenses/GPL-2 (lintian tag copyright-refers-to-symlink-license) | 17:38 |
| rmunn | bdrung, Understood, thanks. | 17:38 |
| bdrung | rmunn: 1. two recommendations: use DEP-3 for the patch 2. use 3.0 (quilt) source format | 17:40 |
| bdrung | (why not use the latest packaging tools for new packages?) | 17:40 |
| * persia notes that due to an outdated dpkg bug in Ubuntu, not all 3.0 (quilt) sources are currently uploadable. | 17:40 | |
| rmunn | bdrung, I created the package on Karmic, haven't moved my main work computer to Lucid yet. Now that I'm getting more experience with packaging, I'll probably start creating packages on a Lucid VM. | 17:41 |
| persia | (which fixing requires not only an update of dpkg, but also some work to integrate that update into Soyuz) | 17:41 |
| bdrung | persia: really? i had no problems so far | 17:41 |
| bdrung | rmunn: you can build the 3.0 (quilt) package on karmic, too | 17:41 |
| persia | bdrung: It depends on the package. Basically, the dpkg in Ubuntu currently has (slightly) different behaviour depending on whether quilt is installed or not, which only catches some packages. | 17:42 |
| rmunn | And I'm not familiar with the deb 3.0 packaging system yet -- any documents I can read about the changes? | 17:42 |
| bdrung | rmunn: http://wiki.debian.org/Projects/DebSrc3.0 | 17:42 |
| rmunn | bdrung, Thanks. | 17:42 |
| bdrung | persia: aha, that thing. building will fail only if the patches do not apply clean (apply with fuzz) | 17:43 |
| bdrung | that's easy to fix | 17:43 |
| bdrung | by just refreshing the patches | 17:43 |
| ari-tczew | persia, bdrung, geser: but now I should make fake syncs based on current method XbuildY right? | 17:44 |
| bdrung | rmunn: for what is the comment in line 10 in debian/rules? | 17:44 |
| bdrung | ari-tczew: i am unsure | 17:45 |
| rmunn | That was created by "dh_make --cdbs" and I never removed it, since I figured if I did need overrides it would remind me to put them after the includes rather than before. | 17:45 |
| persia | ari-tczew: We all agreed you should use "-Xfakesync", but most developers have never heard of that before, so you may not want to try it yet :) | 17:45 |
| rmunn | bdrung, That comment was directed at you, BTW. | 17:45 |
| persia | ari-tczew: -XbuildY is definitely broken. -XubuntuY is potentially inconvenient. You decide, and your sponsor will review. | 17:46 |
| bdrung | rmunn: drop it | 17:46 |
| rmunn | Working on all these changes now, will upload to http://revu.ubuntuwire.com/p/python-nltk once I'm done. Thanks, bdrung and persia. | 17:52 |
| ari-tczew | can someone sponsor fake sync? bug 521411 | 17:53 |
| ubottu | Launchpad bug 521411 in pyelemental "Fake sync pyelemental 1.2.0-2 (universe) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/521411 | 17:53 |
| bdrung | ari-tczew: not with 1.2.0-2build1 :P | 18:02 |
| ari-tczew | bdrung: XfakesyncY is not oficial demand (yet) | 18:03 |
| bdrung | persia: how should we call the version when we rebuild a fakesync? | 18:06 |
| ari-tczew | note: rebuild is only add new revision into debian/changelog | 18:07 |
| bdrung | ari-tczew: yes, but which version string would you use? | 18:08 |
| geser | bdrung, persia: I'd say -Xfakesync(Y+1), so we need a counter after the fakesync | 18:09 |
| bdrung | geser: yes, that was my thought, too | 18:10 |
| ari-tczew | so what's next? | 18:11 |
| ryanakca | persia: Did you spot anything else in turnin-ng or could you advocate it please? (I'm hoping to get it into Lucid) | 18:13 |
| persia | bdrung: Bother. We needed to think about that *before* the mail :) | 18:14 |
| persia | I don't like -XfakesyncY | 18:14 |
| persia | Maybe -Xalmostsync? | 18:15 |
| ari-tczew | persia: please, don't going to be crazy ;-D | 18:15 |
| geser | persia: -XfakesyncbuildY :) | 18:15 |
| persia | Actually, -XfakesyncY is growing on me, because the same sync/merge semantics apply for them as for the first fakesync. | 18:15 |
| ari-tczew | persia: so please just use old and NOT _deprecated_ XbuildY | 18:16 |
| persia | geser: No, I think I like your original suggestion (but please send mail), because we don't want to confuse the tools if we write them. | 18:16 |
| bdrung | persia: -Xsomeidiottookthewrongtarball :D | 18:16 |
| persia | bdrung: :) | 18:16 |
| ari-tczew | and peace | 18:16 |
| persia | ari-tczew: -XbuildY doesn't need to be deprecated. It's just wrong. | 18:16 |
| persia | ari-tczew: If you don't want to wait, use -XubuntuY | 18:16 |
| ari-tczew | persia: FFe is coming soon, I want to upload fake syncs this weekend | 18:17 |
| bdrung | persia, geser: here is my fakesync tool: http://paste.debian.net/59755/ (it works on sync request bugs) | 18:18 |
| ari-tczew | wrrrrrr | 18:19 |
| persia | bdrung: That was fast! Looks reasonable to me (but my python is lousy) | 18:19 |
| ari-tczew | okay, here is my propose: we should use new policy about fakesync, but start with next development cycle, okay? | 18:20 |
| persia | bdrung: Actually, one change: task.transitiontoAssignee(assignee=None) should be changed to reference the person processing the fakesync. | 18:20 |
| bdrung | persia: i wrote the script some time ago. i just updated it today. | 18:20 |
| bdrung | persia: why? we upload the patch directly and it will get closed. | 18:21 |
| persia | ari-tczew: Why link the policy change to development cycles? | 18:21 |
| ari-tczew | persia: because now 5 days remaining to FFe and no sense change fakesync policy | 18:23 |
| persia | bdrung: Because launchpad.me is working on it, in case someone else tries to do something at a similar time? | 18:23 |
| persia | ari-tczew: I don't see how the timing matters at all. | 18:23 |
| persia | ari-tczew: fakesyncs sometimes happen days before release, for things like RCbugs processing. | 18:23 |
| ari-tczew | and new policy is not confirmed by any admins | 18:23 |
| persia | There are no admins to confirm it. | 18:24 |
| persia | Or if you want to consider those who admin the developer membership, geser and I would be (an unquorate) subset of them. | 18:24 |
| ari-tczew | by admins I mean about person like dholbach, ScottK or sistpoty | 18:25 |
| bdrung | ari-tczew: dholbach? | 18:26 |
| ari-tczew | bdrung: why are you suprised? | 18:28 |
| bdrung | ari-tczew: what kind of admin? | 18:29 |
| persia | ari-tczew: Why those specific people? I respect them all, but the first is on CC and the (not-currently-functional) MC, but not otherwise empowered, and the latter two are on the release team (or should be once the release team mess gets sorted). | 18:29 |
| bdrung | do you thought about | 18:29 |
| ari-tczew | omfg | 18:30 |
| ari-tczew | men's decision: what's revision for fakesync? | 18:30 |
| ari-tczew | oficial | 18:31 |
| persia | ari-tczew: -XubuntuY, as I've told you several times. | 18:31 |
| geser | and as this policy change not only affects ~motu but also ~core-dev it should be approved by the TB (if necessary) once a consensus exists | 18:31 |
| persia | geser: Agreed. | 18:31 |
| * persia hopes consensus can be built without bringing it to the TB | 18:32 | |
| bdrung | TB is only for issue where no consensus can be established | 18:33 |
| persia | fabrice_sp: Hey. So there's a new pgadmin3 available in the next Debian dinstall run: you mind watching and pulling that when it's ready? | 18:33 |
| ari-tczew | persia: it is not so obvious, because earlier other person wanted use XfakesyncY | 18:33 |
| persia | bdrung: Or we need some "official" statement for some reason (usually related to interaction with external groups). | 18:33 |
| persia | ari-tczew: I want to use -XfakesyncY : it's just that it's not discussed in depth. Feel free to use that if you want to be a member of the avant-garde | 18:34 |
| fabrice_sp | persia, sure: that was yesterday's plan :-) | 18:34 |
| bdrung | welcome fabrice_sp | 18:34 |
| persia | fabrice_sp: OK. Rhonda stopped by to report the upload, and I'm just passing the message along :) | 18:34 |
| fabrice_sp | :-D | 18:34 |
| fabrice_sp | Hey bdrung | 18:34 |
| fabrice_sp | persia, just reading your email about fakesync: I like the idea of differencing fakesyncs and merges | 18:35 |
| bdrung | fabrice_sp: thanks for uploading openshot. (a simple ACK from you would be sufficient) | 18:35 |
| persia | fabrice_sp: I can't take full credit. geser and bdrung were instrumental to the conclusion. | 18:35 |
| ari-tczew | no ! no ! no ! -100 for XubuntuY fakesync ! please still using XbuildY yet in this development cycle | 18:36 |
| fabrice_sp | bdrung, I only applied revu rule: the second ack'er uploads the package :-D | 18:36 |
| persia | ari-tczew: -XbuildY is known to be wrong in several ways, and doesn't work with the archive-admin scripts. Please don't use it. | 18:37 |
| ari-tczew | omfg | 18:37 |
| fabrice_sp | ari-tczew, no. xbuildy will be automatically synced in next dev, and we may not want that! | 18:37 |
| persia | Or it may just cause the archive-admin scripts to lock up, which annoys archive-admins. | 18:37 |
| bdrung | fabrice_sp: it started 7 hours ago with an discussion between ari-tczew and me. | 18:37 |
| fabrice_sp | arriving late, I see :-D | 18:38 |
| * fabrice_sp checks the log | 18:38 | |
| bdrung | fabrice_sp will be back in one hour (or 30 min if he can read fast) ;) | 18:38 |
| persia | heh | 18:38 |
| fabrice_sp | lol | 18:38 |
| ari-tczew | fabrice_sp: I thought that auto-sync for fakesyncs in next dev cycle it is that what we want to get | 18:39 |
| fabrice_sp | ari-tczew, only if it's a new upstream release. Otherwise, the sync will fail, annoying the archive admin (and we don't want annoyed a-a! :-) ) | 18:40 |
| persia | No, they tend to either send high-temperature email or not bother to process syncs. | 18:41 |
| ari-tczew | fabrice_sp: so auto-sync needs development to differentiate fakesync and clean rebuild | 18:42 |
| bdrung | fabrice_sp: should i put my fakesync script in the ack-sync branch? | 18:43 |
| fabrice_sp | bdrung, that would be great, yes! | 18:44 |
| persia | ari-tczew: Which requires a semantic hint, which is the point of using -XfakesyncY : until that is fixed, use -XubuntuY to work around the bug. | 18:44 |
| bdrung | fabrice_sp: pushed | 18:45 |
| ari-tczew | fabrice_sp, bdrung, geser: are you sure with persia? -XubuntuY until oficial -XfakesyncY ? | 18:46 |
| bdrung | persia: why not use -XfakesyncY now? | 18:46 |
| persia | bdrung: I can't think of any good reason, but ari-tczew seems to not want to do that. | 18:46 |
| fabrice_sp | bdrung, cool! I'll push soon also a test-dsc script that will do the build/piuparts run on a local dsc file (I have to convert it to python :-d ) | 18:46 |
| bdrung | in the worst case, we have to request a sync (which will be the same for -XubuntuY) | 18:46 |
| persia | No, in the worst case, it crashes auto-sync (which would be the same as for -XbuildY) | 18:47 |
| bdrung | k | 18:47 |
| persia | requesting a sync is relatively easy compared to doing a fakesync and requesting blacklist removal. | 18:47 |
| persia | (although your tool will help with that) | 18:47 |
| ari-tczew | so, so, so... men, consensus please | 18:49 |
| geser | ari-tczew: if reaching consensus would be that easy we would need to discuss it | 18:50 |
| persia | ari-tczew: If you want consensus, wait for discussion on the mailing list. Otherwise, please decide what you think is best. The problems with all of the current options have been outlined. | 18:50 |
| bdrung | ari-tczew: +1 for -XubuntuY until oficial -XfakesyncY | 18:50 |
| persia | ari-tczew: If someone disagrees with your decision, you can argue your opinion with them. | 18:51 |
| bdrung | ari-tczew: i would sponsor -XubuntuY | 18:51 |
| geser | ari-tczew: use -XubuntuY for now | 18:51 |
| l3on | Hi all, someone can explain me if this error (http://paste.ubuntu.com/375637/) is serious or not? (debiandoc2latexpdf: ERROR: thumbnail images could not be generated properly). Packages are created and sucessfully installed. | 18:52 |
| geser | l3on: "sh: gs: not found" -> missing build-dependency on ghostscript | 18:53 |
| persia | l3on: Try using dpkg --contents to see if the .debs contain what you wanted | 18:53 |
| ari-tczew | so, I would use -XbuildY, but as explained now, I'll use -Xubuntu1. End. | 18:53 |
| l3on | geser: so I have to add ghostscript in dependences ? | 18:54 |
| l3on | (I'm new in merging :)) | 18:54 |
| persia | ari-tczew: Is there any documentation you've read that specifically asks for -XbuildY? I'm certain enough that is wrong that I want to fix it even before the discussion is completed. | 18:54 |
| geser | l3on: yes, either in Build-Depends-Indep or Build-Depends (didn't look at the packaging) | 18:54 |
| l3on | Yes, it's missed. Adding just "ghostscript" manually, or there is a tool? | 18:55 |
| bdrung | fabrice_sp: now i remembered what i want to tell you: piuparts has no -W parameter (in karmic) | 18:55 |
| ari-tczew | persia: https://wiki.ubuntu.com/PackagingGuide/Wishlist?highlight=%28fakesync%29 | 18:56 |
| fabrice_sp | bdrung, I have to check which version of piuparts I have because I'm running karmic, and ack-sync works perfectly | 18:56 |
| * fabrice_sp is still reading the log :-D | 18:57 | |
| bdrung | :D | 18:57 |
| fabrice_sp | persia, what was that comment about? "* persia looks about for fabricesp and is disappointed" | 19:03 |
| fabrice_sp | just curious :-D | 19:04 |
| persia | fabrice_sp: pgadmin3 :) | 19:04 |
| fabrice_sp | oh, ok :-D | 19:04 |
| persia | You didn't appear to be here, but in case I missed your join, I was hoping you'd ask. | 19:04 |
| fabrice_sp | done then. Thanks for taking care ;-) | 19:05 |
| geser | l3on: you can edit debian/control with your editor | 19:05 |
| l3on | geser: done... and built. | 19:05 |
| * fabrice_sp is back | 19:05 | |
| l3on | geser: what do you think about -> http://paste.ubuntu.com/375661/ ? | 19:05 |
| l3on | seems to be clean. | 19:05 |
| fabrice_sp | interesting to see the discussion about that XfakesyncY notion | 19:05 |
| geser | l3on: looks good | 19:06 |
| l3on | ok, I'm going to upload debdiffs on LP. Thanks geser. | 19:07 |
| fabrice_sp | bdrung, you're right about the -W flag in piuparts: I installed version 0.38 to have that flag | 19:11 |
| bdrung | fabrice_sp: BTW, we may have to port our ack-sync changes to fakesync | 19:14 |
| bdrung | or create a library | 19:14 |
| ari-tczew | I'm going away to have some fun, bye! | 19:14 |
| bdrung | bye | 19:15 |
| l3on | geser: can you take a quick look at bug 521455? Is it the right way to make a merge request? | 19:16 |
| fabrice_sp | bdrung, a lib would be fine. This way, I could use it for local dsc testing/checking | 19:16 |
| ubottu | Launchpad bug 521455 in blends "Please merge blends 0.6.10 (universe) from debian unstable." [Undecided,Confirmed] https://launchpad.net/bugs/521455 | 19:16 |
| bdrung | fabrice_sp: maybe checking python-apt if it can help us | 19:17 |
| geser | l3on: looks ok on a quick look | 19:18 |
| l3on | good geser. Thanks a lot :). | 19:18 |
| fabrice_sp | bdrung, rmember I am at "Dive into python" level :-D | 19:18 |
| bdrung | fabrice_sp: it's the right place to learn it. ;) | 19:18 |
| oojah | Could someone take a few minutes to review http://revu.ubuntuwire.com/details.py?upid=7680 please? I don't think it should be very much work. | 19:25 |
| bdrung | fabrice_sp: python-apt won't help us | 19:26 |
| * fabrice_sp is totally lost :-/ | 19:33 | |
| rmunn | Hmm, REVU may need an update: my latest build of http://revu.ubuntuwire.com/p/python-nltk created a "python-nltk_2.0~b8-0ubuntu1.debian.tar.gz" instead of .diff.tar.gz and REVU doesn't know how to handle those. | 19:47 |
| rmunn | I mean instead of .diff.gz | 19:47 |
| rmunn | Is this a change introduced by the deb 3.0 packaging tools? This is the first source package I created on Lucid rather than on Karmic. | 19:48 |
| asbin | rmunn: you may have a "debian/source/format" file, for the "3.0 (quilt)" format ... | 19:58 |
| bdrung | rmunn: yes, that's the new format (tarballs instead patches) | 19:59 |
| asbin | bdrung: is this format already supported on ubuntu ? Lintian is not ok whith that format ... | 20:02 |
| bdrung | asbin: it's supported and lintian is ok with it. only REVU cannot extract the package. | 20:03 |
| asbin | bdrung: with lintian 2.2.17ubuntu1.1 I get a message "This package uses a different source package format than 1.0." ! | 20:09 |
| bdrung | asbin: use the lintian version from lucid or grab it from https://launchpad.net/~bdrung/+archive/backports | 20:10 |
| rmunn | asbin, yes, I have "3.0 (quilt)" in debian/source/format, so debuild -S created a .debian.tar.gz -- only problem is REVU doesn't know how to extract it | 20:11 |
| asbin | bdrung: hum, ok. As I'm still on karmic I didn't have the last version of course ! | 20:11 |
| asbin | thanks | 20:11 |
| rmunn | Which means I don't get a debdiff at http://revu.ubuntuwire.com/p/python-nltk -- but hopefully it won't make it hard to review | 20:11 |
| rmunn | Question about the REVU code: now that I've made a new source upload, the previous advocation by sistpoty has been invalidated, correct? | 20:12 |
| bdrung | rmunn: the reviewer will probably build it and run lintian on it | 20:12 |
| asbin | rmunn: ok thanks you ! I use 1.0 format in my package http://revu.ubuntuwire.com/p/enna ... BTW I may need advocation for that package please ! :) | 20:13 |
| rmunn | So I'll need to ask sistpoty to re-advocate the new upload? | 20:13 |
| rmunn | asbin, I'm not a MOTU so I can't advocate packages, otherwise I'd be happy to look at it :-) | 20:13 |
| asbin | rmunn: Yes I know :) Good luck for your package ! | 20:14 |
| bdrung | asbin: do you intend to bring the package to Debian, too? | 20:18 |
| fabrice_sp | openshot accepted! :-) | 20:18 |
| asbin | bdrung: yes the package is already waiting on debian mentors :) | 20:21 |
| bdrung | fabrice_sp: wow, they were fast | 20:21 |
| bdrung | asbin: can you link the ubuntu bug to the debian bug? | 20:22 |
| fabrice_sp | bdrung, yeah: the source NEW is generally slower. Now, binary NEW :-D | 20:23 |
| bdrung | :) | 20:23 |
| asbin | bdrung: you mean in the launchpad need-packaging bug ? | 20:23 |
| bdrung | asbin: yes | 20:23 |
| bdrung | fabrice_sp: how high is the change that we get yofrankie into lucid? | 20:24 |
| bdrung | s/change/chance/ | 20:24 |
| fabrice_sp | do you have a link? | 20:24 |
| bdrung | fabrice_sp: i have no source tarball and no debian directory. :D bug #311938 | 20:26 |
| ubottu | Launchpad bug 311938 in ubuntu "[needs-packaging] Yo Frankie!" [Wishlist,Confirmed] https://launchpad.net/bugs/311938 | 20:26 |
| bdrung | fabrice_sp: give me an hour and you get your dsc file | 20:27 |
| fabrice_sp | bdrung, ok ;-) | 20:27 |
| asbin | bdrung: done ! https://bugs.launchpad.net/ubuntu/+bug/519063 | 20:27 |
| ubottu | Ubuntu bug 519063 in ubuntu "[needs-packaging] enna" [Wishlist,New] | 20:27 |
| bdrung | fabrice_sp: but you have to test it (my currently running karmic machine has no 3D) | 20:28 |
| bdrung | asbin: go to "also affected distribution" and set the link there | 20:28 |
| dooooomi | hi, i'm looking for someone to review gtklick, a GTK metronome for JACK, written in Python: http://revu.ubuntuwire.com/p/gtklick | 20:29 |
| bdrung | dooooomi: : do you intend to bring the package to Debian, too? | 20:32 |
| asbin | bdrung: ok, I never used this option ... I've linked it to the debian bug now | 20:33 |
| bdrung | asbin: thanks | 20:33 |
| dooooomi | bdrung: yup, i'll talk to the debian-multimedia guys | 20:34 |
| dooooomi | bdrung: for now i'm hoping to have the package finished in time for lucid | 20:34 |
| fabrice_sp | bdrung, I think it's ok here. What is the command to check? | 20:34 |
| bdrung | dooooomi: can you link the ubuntu bug to the debian bug? | 20:34 |
| bdrung | fabrice_sp: ? | 20:35 |
| fabrice_sp | ·D | 20:35 |
| fabrice_sp | 3D | 20:35 |
| bdrung | fabrice_sp: you have to check if the game works. | 20:35 |
| fabrice_sp | ok | 20:35 |
| * fabrice_sp is getting tired | 20:36 | |
| fabrice_sp | Just put here the link: I'll check the log tomorrow morning | 20:36 |
| dooooomi | bdrung: by debian bug you mean the rfp? | 20:36 |
| bdrung | dooooomi: yes. you should rename the RFP to ITP, when you package it. | 20:37 |
| dooooomi | bdrung: how do i do that? | 20:39 |
| asbin | bdrung: could you review my package enna ? http://revu.ubuntuwire.com/p/enna (if you have time ...) | 20:39 |
| bdrung | dooooomi: http://www.debian.org/devel/wnpp/ -> ITP and http://www.debian.org/Bugs/server-control | 20:40 |
| bdrung | asbin: ping me in a hour again | 20:40 |
| asbin | bdrung: ok thank you ! | 20:40 |
| bdrung | then i might have time for it | 20:41 |
| dooooomi | bdrung: thanks, got some reading to do ;) | 20:42 |
| asbin | what is the current Standards-Version ? 3.8.3 or 3.8.4 ? on REVU, the 3.8.4 is not recognized ... | 20:54 |
| lifeless | asbin: you can check - install the debian-policy doc from lucid, and check /usr/share/doc/debian-policy/* | 20:55 |
| asbin | lifeless: exactly, the debian-policy in lucid is 3.8.4 : http://packages.ubuntu.com/lucid/debian-policy, but on REVU this version is flagged as "newer-standards-version" by lintian ... | 20:58 |
| lifeless | bug in revu | 20:58 |
| ryanakca | 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) | 21:02 |
| persia | lifeless: The "bug in REVU" is that there's no good sparc kernels for karmic or lucid :) | 21:15 |
| lifeless | persia: REVU runs on sparc?! | 21:16 |
| lifeless | persia: cause, that might really be the bug ;> | 21:16 |
| persia | lifeless: Have an extra machine and lots of bandwidth you want to donate? | 21:16 |
| lifeless | persia: yes to the former, I live in Australia to the latter. | 21:18 |
| persia | lifeless: Yeah, well. We have bandwidth available in UK and Germany, but even then shipment gets expensive. | 21:18 |
| persia | But for now, REVU mostly gets by, even if it gets confused sometimes. | 21:19 |
| sistpoty | revu is only as confused as the sparc port is :P | 21:19 |
| sistpoty | (at least it is now, earlier on when I still hacked on it, it was as confused as /me *g*) | 21:20 |
| persia | Well, we have userspace solutions for a lot of it, in one place or another, but the backporting gets messy. | 21:21 |
| persia | If we had a good kernel, we could probably run karmic. | 21:21 |
| sistpoty | once upon a time, I'll simply dist-upgrade the box and then go on vacation :P | 21:23 |
| sebner | sistpoty: to lucid! | 21:25 |
| * sebner hugs sistpoty :D | 21:25 | |
| sistpoty | sebner: to lucid+1 :P | 21:25 |
| sistpoty | hi sebner | 21:25 |
| sistpoty | geser: looking at bug #521380: please apply for core-dev, kthxbye ;) | 21:28 |
| ubottu | Launchpad bug 521380 in dia "Don't use LOCALMODLIBS from python for linking" [Undecided,New] https://launchpad.net/bugs/521380 | 21:28 |
| sebner | geser for core-dev \o/ | 21:30 |
| sebner | sistpoty too \o/ | 21:30 |
| sebner | maybe generalist developer now *g* | 21:30 |
| sistpoty | sebner: I'm already core-dev :P | 21:30 |
| sebner | sistpoty: *haha* but you have to envolve to generalist developer :P | 21:30 |
| * persia remembers that sistpoty holds the record for the shortest-ever core-dev application (and probably always will) | 21:31 | |
| sistpoty | heh | 21:31 |
| sebner | sistpoty: if your life becomes boring you can still become DD :D | 21:31 |
| kamalmostafa | sispoty: fyi I have responded to your question in bug 521164 | 21:32 |
| ubottu | Launchpad bug 521164 in omhacks "omhacks FTBFS: open O_CREAT needs 3 arguments" [Undecided,Confirmed] https://launchpad.net/bugs/521164 | 21:32 |
| sistpoty | sebner: heh, tried that once, but got rejected since I was too lazy *g* | 21:32 |
| geser | sebner: he plans to first break REVU before breaking Debian :) | 21:32 |
| sebner | xD | 21:32 |
| sistpoty | kamalmostafa: looking | 21:32 |
| sebner | breakage everywhere needs to be the goal! | 21:32 |
| persia | Um, no. | 21:33 |
| sistpoty | bdrung: meh, I broke asm3 with sponsoring your merge (looks like javahelper is the one to blame though, as it has a dependency on univers) | 21:35 |
| sebner | persia: you are missing the point. Bleeding edge leads to breakage :P | 21:36 |
| bdrung | sistpoty: got the failed message. javatools was promoted to main. | 21:36 |
| sistpoty | bdrung: ah, so I guess we can retry once the transition to main is complete? | 21:37 |
| sistpoty | bdrung: or does javatools need a no-change upload first? | 21:37 |
| bdrung | sistpoty: javatools is already there. | 21:37 |
| sistpoty | ah, k | 21:38 |
| bdrung | sistpoty: we have to promote python-scriptutil to main | 21:38 |
| sistpoty | bdrung: ah, right, that was it | 21:39 |
| sebner | RainCT: congrats on mistelix :) | 21:42 |
| RainCT | sebner: Haha. Yeah, was about time that it gets uploaded... | 21:43 |
| sebner | RainCT: well, it's your own fault. Just look at your rules file .. I'd never have uploaded it tbh :P | 21:44 |
| rmunn | sistpoty, Would you have time to look at http://revu.ubuntuwire.com/p/python-nltk again? I discovered I had written the wrong bug number in my changelog, so I had to upload a new version of the package -- and so your advocacy yesterday is now out-of-date. | 21:44 |
| * RainCT hits sebner with a stick | 21:44 | |
| * sebner hides | 21:44 | |
| persia | sebner: Oh, did you see that the dpkg-buiildpackage changes required for the dpkg merge required to allow Soyuz to accept alien-arena were uploaded? | 21:44 |
| rmunn | sistpoty, I upgraded the packaging to the "3.0 (quilt" format, but there are no other technical changes, so it should be a fairly quick review when you have time for it. | 21:44 |
| sebner | persia: I'm reading your sentence but I'm not understanding it xD | 21:45 |
| RainCT | sebner: You should be doomed to using CDBS until the end of your days! :D | 21:45 |
| rmunn | Incidentally, I discovered that REVU doesn't know how to handle the 3.0 format -- .debian.tar.gz tarballs break its poor little brain. :-) | 21:45 |
| sebner | RainCT: CDBS would be doomed through me then :P | 21:45 |
| RainCT | rmunn: Yeah, REVU is running on a Hardy box. | 21:45 |
| sebner | + SPARC | 21:46 |
| sebner | poor Revu | 21:46 |
| persia | sebner: You care about https://lists.ubuntu.com/archives/lucid-changes/2010-February/005483.html as the first step towards fixing alien-arena | 21:47 |
| sebner | persia: Yeah I know. After bzr stuff is done cjwatson does the dpkg merge. I heard of it already | 21:47 |
| sebner | persia: Thanks for the hint but we don't want to give cjwatson that much of pressure :P | 21:49 |
| sistpoty | kamalmostafa: you've got a point with umask there, probably I'm just paranoid since the files reside in sysfs ;) | 21:49 |
| sistpoty | kamalmostafa: uploading | 21:50 |
| persia | sebner: Then stop highlighting :) | 21:50 |
| sistpoty | kamalmostafa: oh, i.e. uploading after I've done a test-build, as it looks that I haven't done that yet | 21:51 |
| kamalmostafa | sistpoty: very good, thanks for reviewing and sponsoring it. should build fine for you. :-) | 21:52 |
| sistpoty | kamalmostafa: thanks for the patch in the first place ;) | 21:52 |
| sebner | persia: pssst, that's reverse psychology. He'll feel guilty and makes dpkg top priority once he reads the messages of our poor souls :P | 21:52 |
| sistpoty | rmunn: looking | 21:53 |
| rmunn | sistpoty, Thanks! | 21:53 |
| asbin | bdrung: hi, you ask me to ping you now ;) can you please have a look at enna ? http://revu.ubuntuwire.com/p/enna (if you have the time to ... ) Thanks ! | 21:53 |
| persia | I don't think that works so well. More irc highlighting seems to reduce time for development work. | 21:54 |
| * sistpoty highlights persia and sebner :P | 21:55 | |
| * sebner hugs sistpoty and persia :D | 21:55 | |
| sistpoty | :) | 21:55 |
| * bdrung wonders if sistpoty creates the MIR for python-scriptutil. | 21:55 | |
| sebner | sistpoty: I really think we have too less life and too much time xD | 21:56 |
| * sistpoty would prefer if bdrung would do it | 21:56 | |
| bdrung | let's see if reverse psychology works | 21:56 |
| sistpoty | sebner: heh | 21:56 |
| dupondje | evening :) | 22:10 |
| tsmithe | hi, the upstream for mscore (which i look after) wants to change the [source] package name to "musescore". would the best way to go about doing that to be to upload a new source package, "musescore" which builds binaries using that name, and a new version of "mscore" which builds dummy packages that depend on the musescore packages? should i also have the musescore binaries Provide mscore-named packages, so that the mscore source package can eve | 22:11 |
| tsmithe | ntually disappear? | 22:11 |
| tsmithe | (could this all be done before FF?) | 22:12 |
| lifeless | tsmithe: don't upload a new version of mscore | 22:12 |
| lifeless | just have musescore provide dummy packages too | 22:12 |
| tsmithe | i thought about that. | 22:12 |
| lifeless | its whats normally done | 22:12 |
| tsmithe | but surely then, musescore and mscore would both be in the archives building binaries with the same name? or there could be some timing peculiarities? | 22:13 |
| lifeless | you get the archive admins to remove mscore | 22:13 |
| tsmithe | ok, i'll build the package. is the procedure these days to upload to revu, still? | 22:14 |
| lifeless | dunno; going out now sorry | 22:14 |
| tsmithe | eventually, i'll have it uploaded to debian, but i want it to be definitely in lucid | 22:14 |
| tsmithe | right, cheers for the help | 22:14 |
| persia | tsmithe: Didn't you get mscore into Debian? | 22:16 |
| tsmithe | i did | 22:16 |
| tsmithe | but it's quicker for it to go into ubuntu first, seeing as ff is in 5 days | 22:17 |
| persia | Oh, right, because of NEW :/ | 22:17 |
| tsmithe | i can always sync later :) | 22:17 |
| tsmithe | exactly | 22:17 |
| persia | tsmithe: But you don't need REVU for a source rename: just prepare a new diff.gz and upload it to a bug against mscore. | 22:17 |
| persia | (remembering to create the dummy transitional packages) | 22:17 |
| tsmithe | well, i will also want an updated orig tarball :) | 22:17 |
| tsmithe | i've done all the work, it's just a matter of uploading | 22:18 |
| persia | Right, but you'd get that from either the watch file or the get-orig-source rule, either of which would be in the diff.gz, which your sponsor can pull from upstream. | 22:18 |
| tsmithe | that's tricky, because i want to upload a beta version, which is in actuality a lot more stable than the current version 0.9.5. however, there is no tarball released for it, as it is built from vcs sources. | 22:19 |
| persia | tsmithe: get-orig-source can solve that :) Just document how to construct the tarball in the form of a make rule. | 22:19 |
| persia | tsmithe: But be sure to use a version like 0.9.6~beta-0ubuntu1 so that it can be overridden by the newer release from Debian. | 22:20 |
| tsmithe | of course; it's done. my get-orig-source rule exists, it's just a matter of creating a "get-beta-orig-source" rule to handle the svn case | 22:20 |
| persia | heh. | 22:23 |
| tsmithe | who should i subscribe to the mscore bug? | 22:25 |
| persia | tsmithe: u-u-s (and me, because I want new shiny musescore) | 22:26 |
| tsmithe | you can always use the ppa! ;) | 22:27 |
| persia | I don't use PPAs as a matter of ideology. | 22:27 |
| tsmithe | although.. it is a little out of date :s | 22:27 |
| tsmithe | persia, really? | 22:27 |
| persia | Really. | 22:27 |
| persia | I think the proliferation of third-party repositories is ultimately bad for the health of Ubuntu. | 22:27 |
| tsmithe | but aren't there cases where it's, maybe not necessary, but at least worth-while | 22:27 |
| tsmithe | oh, i agree. but i try to be pragmatic about it. | 22:28 |
| tsmithe | i believe that mscore releases tend to get less buggy as they go on, but in a way that isn't compatible with the release process for ubuntu | 22:28 |
| persia | I believe it discourages people from trying to have their applications included, and encourages weak packaging skills by reducing the value of peer coordination and training. | 22:28 |
| tsmithe | for example | 22:28 |
| tsmithe | that's true, too. but my case is still not a rare one. | 22:28 |
| persia | agreed. | 22:28 |
| tsmithe | the overall stability of ubuntu seems too tightly dependent on specific package versions | 22:28 |
| tsmithe | either we need ppas, or a looser system | 22:29 |
| tsmithe | (but looser doesn't necessitate less rigour) | 22:29 |
| persia | If I were a software developer, I'd love PPAs because it makes for an easy (and mostly safe) way to expose stuff to testers and get feedback. | 22:29 |
| persia | But I'm a distro developer, so I don't :) | 22:29 |
| tsmithe | but, as a distro developer concerned with the future of your distro, don't you want it supported by devs who don't light the apparent barrier to entry, regardless of whether it's there for a good reason? | 22:30 |
| tsmithe | *don't like | 22:30 |
| persia | tsmithe: Out of curiosity, how isn't the musescore release process compatible with the Ubuntu process? | 22:30 |
| persia | tsmithe: I'd rather reduce the perception of barrier-to-entry :) | 22:30 |
| tsmithe | lots of bugs are fixed in 0.9.5/.6 that are present in 0.9.4 (which is in karmic). but isn't it true that new upstream versions (which is what they are) are not desirable in stable ubuntu releases? and, as these fixes are too intrusive to be backportable, they're not really feasible included. and so i popularise the ppa. | 22:31 |
| persia | Ah, because musescore is releasing on a very fast cycle. | 22:32 |
| persia | Well, our ideal process would be for someone to backport only the bugfixes (and not new features). | 22:33 |
| tsmithe | exactly, but that's not really possible in this case. | 22:33 |
| persia | Alternately, to have separate feature vs. bugfix branches by upstream. | 22:33 |
| persia | But yeah, that's often not possible. | 22:33 |
| tsmithe | and, i'm sure it's not just my project that's affected. | 22:33 |
| persia | No, it's any project with a frequent-release model and no long-term support commitment for any releases. | 22:34 |
| tsmithe | i'd prefer ubuntu-proposed (say) to accept new upstream releases on the promise that they were more stable, and then test. | 22:34 |
| persia | The issue is the testing. | 22:34 |
| tsmithe | if the promise is good, then include it (if that's realistic, due to things like compatibility etc) | 22:34 |
| tsmithe | hmm. | 22:34 |
| persia | There are some projects that have that sort of arrangement: it requires approval by the TB. | 22:34 |
| persia | And to have someone specifically caring for it in Ubuntu. | 22:35 |
| asbin | persia: Hi, you remember, you let a comment on enna on REVU http://revu.ubuntuwire.com/p/enna , I had made the necessary changes, so if you want to have a look it will be nice ! :) Thanks | 22:35 |
| persia | But without that level of commitment to Ubuntu by a project, there's a risk to Ubuntu that something might go wrong. | 22:35 |
| persia | For example, I'd really hate to try to explain to my mother why she needs to do something different when she only meant to apply "critical bug fix updates". | 22:36 |
| tsmithe | right. | 22:36 |
| tsmithe | i do specifically care for musescore in as much as i regularly provide new "releases" in the ppa, and respond to queries etc. i also feel that it's a minimal risk kinda thing. but things *do change*, and that would affect documentation and support. | 22:36 |
| persia | Wherein lies the risk in allowing new features. | 22:37 |
| persia | Personally, I understand both viewpoints, but I think the current policies are a reasonable compromise to both allow new stuff in each release, and avoid confusing users who didn't intend to upgrade. | 22:38 |
| tsmithe | and hence the status quo | 22:38 |
| persia | Right. | 22:38 |
| tsmithe | i agree that we have a good compromise. | 22:38 |
| persia | But we try to make the release cycles relatively short, to avoid getting too out of date. I'm not sure there's a perfect answer. | 22:39 |
| paissad | guys, i have this error during lintian run --> changelog-should-mention-nmu <-- after i decided to rebuild the package http://pastebin.com/f2740a888 | 22:39 |
| tsmithe | and my situation is such that, when i do want to get a new release in ubuntu, because i keep care of the packages regularly, there's not too much change i need to make. | 22:39 |
| tsmithe | paissad, not that i know the specific error, but run "lintian -i" for an explanation | 22:39 |
| paissad | i've read the lintian tags info but i'm a lil bit confused | 22:39 |
| SoftwareExplorer | Hi. I'm trying to package a gtk module. It's only a single .c file, that didn't come with a make file. I read about making a simple make file at http://ubuntuforums.org/showthread.php?t=497200, and got it to compile with that. However, before the makefile you would install the file with sudo cp. How do I modify the makefile so that I can start packaging it like http://www.youtube.com/watch?v=zKLabbXTqMc explains? I can p | 22:40 |
| persia | paissad: What revision string did you use? What name is listed as "Maintainer", and what name is listed in the last changelog entry? | 22:40 |
| paissad | tsmithe, lintian-info --tags ... i did it | 22:40 |
| tsmithe | in ubuntu, i think that one's ignorable because of the maintainership situation (use the motu team, normally); i'll let persia take care of this :) | 22:40 |
| persia | SoftwareExplorer: Just compile it directly in debian/rules build: with gcc | 22:40 |
| tsmithe | right | 22:40 |
| * tsmithe disappears | 22:40 | |
| persia | tsmithe: I'll grab musescore in a few hours. Thanks for pushing to get it in. | 22:41 |
| persia | (unless someone else uploads it first) | 22:41 |
| tsmithe | no problem, and thank you. | 22:41 |
| SoftwareExplorer | Ok, so I should read up on how debian/rules works? | 22:41 |
| persia | SoftwareExplorer: It's a makefile. | 22:41 |
| persia | http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules | 22:42 |
| tsmithe | persia, can i talk to you about a new python package later this week, as well? ideally, it needs to go to debian. (it's called "pisa" if you want to briefly look at the description in ppa:mscore-ubuntu) | 22:42 |
| bdrung | asbin: sorry. it's too late now for me. will have a look at it tomorrow. just ping me again then | 22:42 |
| SoftwareExplorer | Ok, I guess I'm learning makefile as I go. | 22:42 |
| asbin | bdrung: OK no problem, thanks :) | 22:43 |
| paissad | persia, here is the changelog http://pastebin.com/f54122855 --> pms-linux_1.20.392-1.1_all.deb and here is the control file http://pastebin.com/f550683f0 | 22:43 |
| bdrung | SoftwareExplorer: makefiles are easy to learn except you write makefiles like http://code.google.com/p/gnome-colors/source/browse/trunk/gnome-colors/Makefile ;) | 22:44 |
| persia | paissad: "DIAKHATE Papa Issa <paissad@gmail.com>" != "Papa Issa DIAKHATE <paissad@gmail.com>" and the revision is -1.1 | 22:44 |
| paissad | persia, that's all o0 | 22:45 |
| paissad | oops | 22:45 |
| SoftwareExplorer | bdrung: Is there a web page that explains make files well enough to get me started with out takeing a couple of hours to read? | 22:45 |
| persia | paissad: Yep. The tools noticed the difference, and thought you weren't you. | 22:45 |
| persia | bdrung: It can get better than that: http://bazaar.launchpad.net/~persia/+junk/moblin-analysis/annotate/head:/Makefile | 22:46 |
| bdrung | persia: that makefile is dead simple. no foreach, no call, ... | 22:47 |
| persia | Um, read it again then :) | 22:47 |
| * persia has nested calls in foreaches, etc. | 22:47 | |
| persia | OOh, and foreaches in calls :) | 22:47 |
| bdrung | SoftwareExplorer: the long way: http://www.gnu.org/software/make/manual/make.html or just google for makefile tutorial | 22:48 |
| SoftwareExplorer | bdrung: Ok, Thanks. | 22:48 |
| bdrung | persia: found them, but my makefile is longer ;P | 22:49 |
| persia | bdrung: Yes, much. I just think mine happens to be a nice example of nested recursion :) | 22:50 |
| * persia is especially proud of PICK_FILE | 22:50 | |
| bdrung | yes, PICK_FILE is nice | 22:51 |
| persia | But I failed to use define at all, which perhaps makes it less fun :) | 22:52 |
| matttbe | Hi, | 23:18 |
| matttbe | I'm part of the Cairo-Dock team and I've a little question: I've downloaded the ubuntu branch of Cairo-Dock and I've updated it. Do I have to commit with a message respecting some rules? Can I push my merge proposal branch everywhere in Launchpad or not? | 23:18 |
| matttbe | Thanks for your help ! | 23:18 |
| bdrung | asbin: wrote a comment to http://revu.ubuntuwire.com/p/enna | 23:20 |
| matttbe | gilir has answered to my question, thanks ! | 23:21 |
| asbin | bdrung: great thanks ! | 23:21 |
| bdrung | asbin: yw | 23:23 |
| tsmithe | aargh ffs, just deleted my got-orig-source with a careless rm. there goes another hour downloading :s | 23:54 |
| tsmithe | (and a further half hour to do a final pbuild..) | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!