=== pace_t_zulu_ is now known as pace_t_zulu
=== kklimonda1 is now known as kklimonda
[02:48] <Rcart> Ubuntu native packages are patchless? I get that from what-patch on ubiquity-slideshow-ubuntu, and no patch signs in debian/changelog
[02:49] <psusi> Rcart, I would think so, since there is no upstream orig to patch
[02:51] <Rcart> psusi: Maybe. I'll fix some typos in bug 725217
[02:51] <ubottu> Launchpad bug 725217 in ubiquity-slideshow-ubuntu (Ubuntu) "Typos in Edubuntu 11.04 slideshow" [Undecided,New] https://launchpad.net/bugs/725217
[02:54] <Rcart> psusi:  Would be enough to mention it in changelog, right?
[02:54] <psusi> Rcart, enough what?
[02:57] <Rcart> enough to mention that I fixed some typos
[02:58] <lesliev> hi everyone! I just fixed a small crasher bug in a ruby program, part of the rbbr package.. is it best to try patch the ubuntu package or try to send the patch upstream?
[03:10] <Rcart> lesliev: I would send it to Debian, I understand that is better to request a merge (:
[03:14] <lesliev> Rcart, any hints on how to do that?
[03:16] <lesliev> should I find a debian maintainers IRC channel? a forum? a website? I am not running Debian so I wouldn't be able to build a debdiff
[03:16] <Rcart> lesliev:  file a bug in Launchpad, report it to Debian too (using submittodebian) and mention the LP bug, then you should add a bugwatch to the LP bug report
[03:16] <lesliev> ok
[03:18] <lesliev> kthxbai!
[03:18] <highvoltage> hey Rcart
[03:19] <Rcart> highvoltage: Hello.
[03:21] <highvoltage> Rcart: I guess that's something we should handle as part of translations instead
[03:23] <highvoltage> (referring to bug 725217)
[03:23] <ubottu> Launchpad bug 725217 in ubiquity-slideshow-ubuntu (Ubuntu) "Typos in Edubuntu 11.04 slideshow" [Undecided,New] https://launchpad.net/bugs/725217
[03:23] <Rcart> highvoltage: about ubiquity-slideshow-ubuntu ? If so, I asked (well, a contact did it for me) in -translators and there were no response
[03:24] <Rcart> highvoltage: But I also think that it should be handled in tranlations team
[03:28] <Rcart> highvoltage: I'll un-assign. Thanks for the comment.
[03:29] <highvoltage> Rcart: you're welcome
[03:30] <highvoltage> Rcart: there should be new slideshows soon though (at least for edubuntu)
[03:33] <Rcart> highvoltage: Surely. There's something about it in the changelog
=== milli` is now known as milli
[04:19] <c2tarun> How can I apply the debdiff uploaded on a bug and check whether its working or not?
[04:25] <achiang> c2tarun: do you have more context around your question?
[04:26] <achiang> c2tarun: without knowing more, i'd say: apt-get source <package> ; patch -p1 < debdiff.patch ; dpkg-buildpackage
[04:26] <achiang> but that's very broad and handwavey
[04:27] <c2tarun> achiang: suppose anyone worked on a bug and uploaded a debdiff b/w the source packages. And I want to check whether his debdiff is working or not?
[04:27] <achiang> c2tarun: right, ok -- so get the current source package, and use patch(1) to apply the debdiff
[04:28] <achiang> c2tarun: i mean, that's how i would do it. there are probably smarter ways
[04:28] <c2tarun> achiang: well I dont know any way so any way is smart for me ;)
[04:29] <achiang> c2tarun: a debdiff is just a normal patch, so you can use the patch command to apply it. 'man patch' for more details there
[04:29] <c2tarun> achiang: what is num denotes here?
[04:29] <c2tarun> I mean digit after p
[04:29] <achiang> c2tarun: but again, in broad terms, you a) save the debdiff somewhere, say, foo.debdiff and then b) patch -p1 < foo.debdiff
[04:30] <StevenK> c2tarun: The digit tells patch how many path elements to strip
[04:30] <StevenK> -p0 means don't strip any, -p1 says drop the first
[04:30] <achiang> c2tarun: there are several styles to generate a diff. some people generate from *within* the source tree, some generate from outside the source tree
[04:31] <achiang> c2tarun: depending on *where* you generate the diff, you will have different paths to the filename you want to actually patch
[04:31] <c2tarun> achiang: what do you mean by within or outside the source tree, normally .dsc are outside the source tree (I guess)
[04:31] <achiang> c2tarun: so, as StevenK says, you use the -pN arg to strip out the paths you don't want, so that eventually, the paths match up
[04:32] <achiang> c2tarun: here's a very short example: say my package is foo, and i am in: /home/achiang/Projects/foo/
[04:32] <achiang> i want to modify bar.c
[04:32] <achiang> so i say:
[04:32] <achiang> cp bar.c bar.c.old
[04:32] <achiang> # hack on bar.c
[04:32] <achiang> diff -Nurp bar.c.old bar.c > my-lovely-patch
[04:33] <achiang> that is what i mean by making a diff from *within* the source tree
[04:33] <achiang> now contrast a different method:
[04:33] <achiang> $ pwd
[04:33] <achiang>  /home/achiang/Projects
[04:33] <achiang> cp -a foo foo.old ; ls -F
[04:33] <achiang> foo/ foo.old/
[04:34] <achiang> same thing, hack on foo/bar.c
[04:34] <achiang> now i can say:
[04:34] <achiang> diff -Nurp foo.old/bar.c foo/bar.c > my-lovely-patch
[04:34] <achiang> and that generates essentially the same diff, but the path on how you get to bar.c is slightly different
[04:35] <achiang> so on the other end, when you want to apply the patch, you need to pass -pN appropriately, so that patch knows how to get to bar.c
[04:35] <achiang> generally, debdiffs are more similar to the second method, so you typically just say -p1
[04:35] <c2tarun> achiang: ok, got it :)
[04:35] <c2tarun> achiang: thanks for the example :)
[04:36] <achiang> anyway, hopefully that gives you enough of a conceptual understanding so you can figure out how to recover when a patch doesn't apply (when you think it should)
[04:36] <achiang> the details are in the patch and diff man pages. :)
[04:36] <c2tarun> achiang: sure thanks :)
[04:36] <achiang> np
[04:41] <c2tarun> can anyone please look at bug 728438 the patch seems to work fine for me but may not be working on sponsors system, What's wrong with the patch?
[04:41] <ubottu> Launchpad bug 728438 in clips (Ubuntu) "Package clips 6.24-3 failed to build from source" [Undecided,Incomplete] https://launchpad.net/bugs/728438
[05:25] <c2tarun> what does this mean in a Makefile LIBS=@LIBS@
[06:02] <c2tarun> !makefile
[06:10] <jmarsden> c2tarun: The make manual is online at http://www.gnu.org/software/make/manual/make.html
[06:13] <c2tarun> jmarsden: I am reading that manual but stil didn't find anything about @ symbol. can you please help me a big
[06:13] <c2tarun> big =bit
[06:14] <jmarsden> Maybe... I'm bust doing something else here... and I am not a make expert at all.  I think the @something@ syntax is autotools more than Make... are you seeing that in a Makefile, or in Makefile.am or Makefile.in ?
[06:15] <jmarsden> s/bust/busy/ :)
[06:15] <c2tarun> jmarsden: Makefile.in
[06:16] <jmarsden> Aha.  That is not a Makefile :)   You said: <c2tarun> what does this mean in a Makefile LIBS=@LIBS@
[06:16] <c2tarun> jmarsden: but the changes I made in Makefile.in is getting reflected in Makefile, but when changing Makefile all the changes are reset on building
[06:16] <jmarsden> Now you need to read the autotools docs... let me find a linke for that
[06:16] <jmarsden> Yes, the Makefile.in is a template for a Makefile
[06:16] <jmarsden> You need to understand autotools for the details...
[06:17] <jmarsden> Autotolls Tutorial: http://markuskimius.wikidot.com/programming:tut:autotools/
[06:17] <c2tarun> !autotools
[06:17] <c2tarun> jmarsden: thanks :)
[06:18] <jmarsden> The real autotools manual / book is elsewhere... one book is free online at http://sources.redhat.com/autobook/
=== soren_ is now known as sorne
=== sorne is now known as soren
[08:12] <dholbach> good morning
=== directhe` is now known as directhex
=== runasand_ is now known as runasand
=== KKmos is now known as Kmos
=== fta` is now known as fta
[10:39] <nonix4> Does it make sense to report usability bugs in undocumented parts of programs, or should the existence of undocumented features be reported as a bug instead?
=== fabo__ is now known as fabo
[12:39] <cgroza> Hello, I have a deb file of my program and I would like to submit it to Ubuntu. What do I have to do?
[12:41] <cgroza> Anyone?
[12:42] <Bachstelze> cgroza: for new packages, it's generally better to submit them to Debian
[12:43] <Bachstelze> but you can always upload the source package somewhere and have someone look at it
[12:43] <Bachstelze> I'd be surprised if your package was Debian Policy-compliant on the first try :)
[12:45] <cgroza> I may need more info
[12:45] <cgroza> how do i get it to debian?
[12:48] <c2tarun> Can anyone please take a look at this debdiff. http://paste.kde.org/6451/ I just added one library to Makefile.in and I got this debdiff so long
[12:48] <ari-tczew> c2tarun: is there any patch system?
[12:49] <Bachstelze> c2tarun: ²why did you not add -lX11 to LIBS?
[12:49] <c2tarun> ari-tczew: no there is no patch system
[12:50] <c2tarun> Bachstelze: because I found a line LIBS=@LIBS@ I dont understand it, I tried to read few manuals but still didn't got it. so I added directly.
[12:50] <Bachstelze> cgroza: http://wiki.debian.org/Maintainers
[12:51] <cgroza> ok
[12:51] <cgroza> thank you
[12:51] <ari-tczew> c2tarun: LIBS=@LIBS@ -lX11
[12:52] <c2tarun> ari-tczew: oh.... I'll try that. but what is meaning of @ symbol in Makefiles?
[12:52] <Bachstelze> as you were told already, it's not a Makefile thing
[12:52] <Bachstelze> it's used by autotools
[12:54] <c2tarun> Bachstelze: ok, its used by autotools, but autotools use Makefile.in as a template to generate Makefile. I guess Makefile.in is written by user. I found @ symbol in Makefile.in.
[12:56] <c2tarun> ari-tczew: after adding -lX11 to LIBS I am getting the same length debdiff.
[12:57] <ari-tczew> c2tarun: so clean up it manualy
[12:57] <Bachstelze> c2tarun:
[12:58] <Bachstelze> oops
[12:58] <Bachstelze> mMakefile.in is generated by automake, not written by the user
[12:59] <c2tarun> ari-tczew: there is one more prob, when I tried to apply this debdiff to a fresh new copy it is detecting some previously applied patch, but I dont see any patch in there, though in diff.gz file there are some changes.
[12:59] <c2tarun> Bachstelze: still I failed to find the meaning of @ symbol :( can you please tell me.
[13:00] <c2tarun> ari-tczew: I dont understand what do you mean by cleaning manually, do I delete the lines I dont understand why there are there?
[13:00] <ari-tczew> c2tarun: probably changes during build
[13:00] <ari-tczew> c2tarun: keep only that you did on package
[13:01] <Bachstelze> c2tarun: it's really just variable subsitution, @var@ in Makefile.in means that @var@ is rerplaced by the value of var in the written Makefile
[13:01] <c2tarun> Bachstelze: oh... just that :) and I find some more symbols in there like $^ and $@ what are they?
[13:03] <Bachstelze> you mean $< ?
[13:03] <Bachstelze> those are make special variables
[13:03] <Bachstelze> $@ means the name of the target, $< means the name of the first dependency
[13:03] <Bachstelze> there are more, they're all in the make manual
[13:04] <c2tarun> Bachstelze: the one there on debian site :( that is 230 pages long manual
[13:05] <Bachstelze> http://www.gnu.org/software/make/manual/make.html#Quick-Reference
[13:08] <Bachstelze> I'm looking at the pâckage, you might need to add dh_autoreconf to your rules files
[13:11] <c2tarun> Bachstelze: how to add it, I am reading the man page, there is not any thing about how to use, should I simply write it down in rules file?
[13:15] <Bachstelze> Ino, never mind, dh_autoreconf is if you modify configure.in
[13:15] <Bachstelze> which is a bit cleaner than modifying Makefile.in, but I guess Makefile.in will do
[13:17] <c2tarun> Bachstelze: on modification of makefile.in I am getting fairly huge debdiff and on applying also I am getting reverse patch detected. wait let me show you the debdiff
[13:18] <Bachstelze> you did already ;)
[13:18] <ari-tczew> tumbleweed: around?
[13:18] <c2tarun> Bachstelze: check this out http://paste.ubuntu.com/575467/
[13:18] <tumbleweed> ari-tczew: hi
[13:19] <ari-tczew> tumbleweed: hi. could you manage to create a script pull-snapshot-source?
[13:19] <Bachstelze> c2tarun: then yes, it is actually A LOT cleaner to modify configure.in and use dh_autoreconf
[13:19] <Bachstelze> c2tarun: just a sec, I'll do a debdiff and pastebin it so you cna see how it's done
[13:19] <c2tarun> Bachstelze: sure :) thanks
[13:24] <ari-tczew> tumbleweed, geser: I got this error while requesting sync: http://pastebin.ubuntu.com/575469/
[13:24] <ari-tczew> does it need bugtracking?
[13:25] <ari-tczew> btw. bug filled successful
=== yofel_ is now known as yofel
[13:34] <c2tarun> Bachstelze: ping
[13:35] <tumbleweed> ari-tczew: oh, that should be easy, pull-debian-source already supports snapshot, I just need to make it take version numbers as well as release names
=== Quintasan_ is now known as Quintasan
[13:37] <Bachstelze> I get all the crud too, I guess autotools regenerates config.guess and config.sub anyway, it should still work if you ditch those changes from your debdiff
[13:37] <Bachstelze> c2tarun: ^
[13:38] <c2tarun> crud?
[13:38] <c2tarun> Bachstelze: oh you mean you are getting almost same debdiff
[13:38] <Bachstelze> yeah
[13:39] <Bachstelze> I mean all the unrelated stuff
[13:39] <c2tarun> Bachstelze: but after dropping those changes also on applyin it to fresh source code, I am getting some reverse patch error.
[13:40] <c2tarun> Bachstelze: check this http://paste.kde.org/6452/
[13:42] <kklimonda> james_w: what is the address of the page I can check branch import failers on? ubuntu:ruby1.8 branch is ancient
[13:43] <tumbleweed> kklimonda: http://package-import.ubuntu.com/status/
[13:43] <kklimonda> thanks
[13:44] <james_w> thanks tumbleweed
[13:47] <Bachstelze> c2tarun: actually, config.sub and config.guess are not regenerated by autotools, they are copied by debian/rules
[13:48] <c2tarun> Bachstelze: so what should I do?
[13:48] <c2tarun> Bachstelze: and copied by debian/rules means? rules file is common config.guess and .sub should also b common b/w older and newer version
[13:49] <tumbleweed> c2tarun: read autotools-dev's README.Debian for a background on that situation (although IIRC the recommendations in there are outdated)
[13:49] <Bachstelze> it means that debian/rules copies config.guess and config.sub from /usr/share/misc to the source dir
[13:51] <c2tarun> Bachstelze: and why is only newer version of rules file doing that? I mean rules are common so it should have been copied in previous version as well, so why the difference?
[13:52] <tumbleweed> (without having followed this whole discussion) easy recommendation is to just strip config.* out of the debdiff. If a package from debian doesn't clean properly, that's not necessarily something we have to fix
[13:53] <c2tarun> tumbleweed: I tried that, but on applying it to fresh copy of source code I am getting this error http://paste.kde.org/6452/
[13:53] <tumbleweed> c2tarun: that means Makefile.in is already patched
[13:53] <tumbleweed> are you sure it was fresh?
[13:55] <tarun> tumbleweed: sorry I got disconnected,
=== tarun is now known as Guest68165
[13:56] <ari-tczew> tumbleweed: really? pull-debian-source supports snapshot.debian.org already? how?
[13:57] <tumbleweed> ari-tczew: if it can't find the version you want from lp, or a mirror, or the master, it'll go to snapshot.debian.org
[13:57] <tumbleweed> but you can only request releases, not versions
[13:57] <tumbleweed> so I just have to add a way for the suer to request a version
[13:58] <tumbleweed> ari-tczew: look at pull-debian-debdiff, that'll almost always use snapshot.debian.org
[13:58] <ari-tczew> tumbleweed: I imagine that scripts as: $ pull-snapshot-source package version
[13:58] <tumbleweed> ari-tczew: yeah, that's what I intend to do, if version doesn't match a known release name
[13:59] <ari-tczew> aha
[13:59] <Bachstelze> c2tarun: http://paste.ubuntu.com/575486/ this debdiff works fine here
[14:01] <Bachstelze> the new config.guess and config.sub will still appear in the .diff.gz when you build the source package, but nothing you can do about it
[14:02] <ari-tczew> tumbleweed: did you see my traceback from requestsync? I posted it here some minutes ago.
[14:02]  * tumbleweed reads back
[14:03] <tumbleweed> hmm, I've had similar issues, goes off to poke #launchpad peopel
[14:04] <Bachstelze> woops typo, -lXII...
[14:04] <c2tarun> Bachstelze: yup :) fixed that and it applied :)
[14:05] <Bachstelze> also, the old debian/rules was doing that as well
[14:06] <Bachstelze> what you're seeing is the difference betwwen config.guess and config.sub now, and as they were the last time the package was built
[14:07] <Bachstelze> which was a long time ago, if you read debian/changelog
[14:20] <kklimonda> hmm.. when I work on a package update using UDD, should I unapply all patches before merging new upstream version?
[14:21] <kklimonda> if I don't do that I can't figure out how to deal with patches that don't unapply cleanly.
[14:30] <plainas> heya
[14:31] <plainas> so i have a debian folder in my python project with my control file, rules, etc.... is it possible to set the application to run at startup?
[14:31] <tumbleweed> kklimonda: you are using merge-upstream, right?
[14:32] <kklimonda> tumbleweed: yes
[14:32] <tumbleweed> kklimonda: I can't remember how I've dealt with this before, but I can't see how unapplying all patches before merging would help
[14:33] <tumbleweed> unless you commit the patch reversal
[14:34] <kklimonda> tumbleweed: yeah, I'd probably try doing something like that and it wouldn't be nice.
[14:34] <tumbleweed> aah, so, IIRC, after you've merge-upstream-ed, it leavs you with the debuntu-modifications, uncommitted
[14:35] <tumbleweed> so you can bzr revert all the upstream stuff, get the quilt patches to apply, apply them, commit
[14:37] <Laney> what's the point of the revert?
[14:37] <tumbleweed> so you don't have to deal with the conflict,s and fix the patches twice
[14:37] <tumbleweed> (once in the applied versions, once in the patches)
[14:38] <Laney> I thought it would be; quilt pop; merge-upstream; quilt push (and fix conflicts); commit
[14:38] <tumbleweed> Laney: merge-upstream operates on the branch (things that have been committed), not yoru workdir
[14:39] <Laney> oh ok, that is uncool
[14:39] <tumbleweed> but I'm talking from memory, I haven't had to do this in a while
[14:39] <tumbleweed> of course quilt-as-loom will get around all this when that happens :)
[14:40] <Laney> I just avoid 3.0 (quilt)
[14:40] <Laney> or use unapply-patches
[14:40] <Laney> http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/
[14:40] <tumbleweed> if you are working on random universe packages in UDD, yo udon't really get that choice.
[14:41] <kklimonda> this list is great if you maintain package.. right
[14:41] <kklimonda> and we keep .pc in bzr
[14:41] <tumbleweed> yeah, I really hate that
[14:41] <kklimonda> except when we don't
[14:41] <tumbleweed> heh
[14:41] <tumbleweed> we do with 3.0 (quilt), we don't with 1.0 + quilt
[14:42] <kklimonda> I've worked with transmission packaging in git (that's how debian maintainer keeps it) and it makes much more sense
[14:42] <kklimonda> it's not as magical
[14:42] <kklimonda> but feels more solid
[14:43] <tumbleweed> I think patches-applied makes sense when you are maintaining your package in git, and pulling from upstream's git, less so for most MOTU tasks
[14:44] <psusi> if you are doing that though, why bother using quilt at all?
[14:44] <kklimonda> I wonder about that myself
[14:45]  * tumbleweed doesn't have any packages like that, I'm hypothesising :) But people in situation slike that seem to be proponents of patches-applied, and it vaguely makes sense
[14:45] <psusi> seems like if you are going to track the packages with quilt then track them with quilt ( and leave them unapplied in the archive )... if you are going to track with git or bzr, then track changes with that and don't bother with quilt
[14:46] <kklimonda> isn't it why 3.0 (git) format has been created?
[14:46] <kklimonda> is it used by any package?
[14:46] <tumbleweed> kklimonda: it was NACKed by the ftp-masters
[14:48] <kklimonda> tumbleweed: no wonder I've heard no news about it - do you remember the reason? or link?
[14:48] <psusi> all I know is that it makes the vcs change log look like a mess when you have changes both to the original source, and bundled as a diff in patches/ and has got to be a needless duplication of effort...
[14:49] <kklimonda> I've had the dream where every distribution, and every project switches to git and we can just do it all in git.. ;)
[14:49] <psusi> hehehe, amen ;)
[14:51] <tumbleweed> kklimonda: lists.debian.org/87wrrxhlr7.fsf@windlord.stanford.edu
[14:53] <kklimonda> thanks
=== jtimberman_ is now known as jtimberman
=== kim0_ is now known as kim0
[15:32] <c2tarun> Is anything wrong with debian bugtracker? I submitted two bugs (one at least half an hour ago) and I didn't got any mail for the bug number.
[15:34] <hakermania> micahg: Hello :) What's going on with Wallch, buddy :) ?
[15:35] <micahg> hakermania: sorry, it's been a busy week, will try to take a look over the weekend
=== psusi` is now known as psusi
=== shadeslayer_ is now known as shadeslayer
[15:38] <tumbleweed> c2tarun: you sure you sent it from the right address? Did the bug get filed (can you see it on the web interface, under the package you filed it against?)
[15:38] <c2tarun> tumbleweed: I filed few more by same method. let me check on debian page
[15:38] <tumbleweed> also, I think the BTS does greylisting, so it may take a while before the message is accepted...
[15:40] <c2tarun> tumbleweed: sure I'll wait :)
[15:45] <dholbach> Last day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 15 minutes in #ubuntu-classroom
[15:49] <hakermania> micahg: OK, no problem :) Take your time!
[15:50] <kklimonda> dholbach: any chance you could add me to ubuntu-sponsors?
[15:50] <dholbach> kklimonda, sure, just a sec
[15:51] <dholbach> kklimonda, done
[15:51] <kklimonda> thanks
=== kees_ is now known as kees
=== didrocks1 is now known as didrocks
[16:03] <debfx> kklimonda: the qwebview designer plugin is going to return soon :)
[16:03] <kklimonda> debfx: awesome :)
=== milli is now known as 84XAAB32R
=== cody-somerville_ is now known as cody-somerville
=== Bachstel1e is now known as Bachstelze
=== popey_ is now known as popey
=== Quintasan_ is now known as Quintasan
=== dpm_ is now known as dpm
=== maxb_ is now known as maxb
[16:56] <MTecknology> If something was originally GNU GPLv2 and a fork was made from it; can the fork be DEP-5 ?
=== ttx` is now known as ttx
=== nxvl_ is now known as nxvl
[16:57] <micahg> MTecknology: DEP-5 is a documentation standard, not a license
[16:57] <MTecknology> or is DEP-5 not a license: I've never seen it before so I'm kind of confused
[16:58] <MTecknology> oh..
[16:59] <MTecknology> micahg: thanks :)
=== adamhorden_ is now known as adamhorden
=== tremolux_ is now known as tremolux
=== _jason is now known as jrib
=== ampelbein_ is now known as Ampelbein
[17:21] <geser> ari-tczew: re your requestsync crash: does it happen every time? (I didn't had any sync request to file in the recent past so didn't use requestsync recently)
[17:49] <ari-tczew> geser: I got it once and dunno whether it happens every time - no point to use requestsync anymore ATM. Problem has been resolved. More questions, ask tumbleweed.
[17:53] <tumbleweed> geser: yes, it would happen every time, it was due to a stale WADL cache
[17:54]  * micahg is still using requestsync 
[17:55] <geser> tumbleweed: is this a problem of requestsync and should it do something about it?
[17:55] <tumbleweed> geser: it's a problem with launchpadlib, they are aware of the issue
[17:55] <tumbleweed> (well there's an open bug)
[17:56] <kklimonda> is ther use of syncpackage still discouraged by archive admins?
[17:56] <micahg> also fails on maverick backport, so if there are minimum version requirements, they should be specified
[17:56] <tumbleweed> micahg: what fails, and how?
[17:56] <ari-tczew> micahg: I mean that I don't have a demand to use requestsync. It doesn't mean that I don't request syncs anymore.
[17:56]  * micahg upgrades again so it can fail
[17:56] <tumbleweed> kklimonda: yes
[17:58] <tumbleweed> geser: for the record, bug 714621
[17:58] <ubottu> Launchpad bug 714621 in Launchpad itself "Reevaluate our WADL caching strategy under continuous deployment" [High,Triaged] https://launchpad.net/bugs/714621
[17:59] <micahg> tumbleweed: weird, it seems to want to work now, last night it was temperamental
[17:59] <tumbleweed> micahg: any recollection what the issue was?
[18:01] <micahg> python backtrace of some sort, I think when polling the packages
[18:02] <tumbleweed> micahg: try requestsync firestarter, does it show you th eduplicate
=== psusi` is now known as psusi
[18:03] <tumbleweed> (--lp of course)
=== jhelwig_ is now known as jhelwig
[18:03] <micahg> tumbleweed: I was having some trouble with authorization last night, that could've been it
[18:04] <micahg> tumbleweed: ah, that did it, got a backtrace, do you want to see it?
[18:04] <tumbleweed> micahg: was it something about a missing web_link attribute?
[18:04] <micahg> tumbleweed: yes
[18:04] <tumbleweed> micahg: rm -rf ~/.launchpadlib/*/cache
[18:04] <tumbleweed> and it'll work again
[18:05] <micahg> that's the WADL stuff?
[18:05] <tumbleweed> yeah
=== didrocks1 is now known as didrocks
[18:05]  * tumbleweed must run
[18:05] <micahg> tumbleweed: thanks and have a good weekend
[18:27] <ari-tczew> if package in main Depends on package in universe, move it in d/control to Recommends is enough?
[18:28] <ari-tczew> I'm merging sane-backends with Debian and in delta we have moved it from Depends to Suggests, but Debian moved it to Recommends.
[18:28] <ari-tczew> If Recommends is fine, I'd like to stick with Debian.
[18:29] <ari-tczew> Advices are welcome. ;-)
[18:31] <geser> My guess is it should stay in Suggests for Ubuntu
[18:32] <ari-tczew> geser: why?
[18:32] <geser> I'm not fully sure about it but as Recommends are installed by default nowadays, Recommends for packages in main should be available in main
=== kees_ is now known as kees
[18:33] <ari-tczew> geser: Would be nice to look into technical documentation.
[18:34] <geser> I'm trying to find something
[18:35] <geser> which either supports or contradicts my statement
[18:35] <mr_pouit> I think it should stay in suggests too
[18:36] <geser> ari-tczew: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-main
[18:37] <geser> * must not require a package outside of main for compilation or execution (thus, the package must not declare a "Depends", "Recommends", or "Build-Depends" relationship on a non-main package)
[18:38] <ari-tczew> geser, mr_pouit: OK, I'll keep them in Suggests. Thanks geser.
[19:03] <mr_pouit> grmpf, requestsync now asks me to authorize it on LP at every call…
[19:04] <geser> mr_pouit: with python-launchpadlib 1.9?
[19:05] <mr_pouit> geser: no, 1.8.0-2
[19:06] <geser> which Ubuntu version are you running?
[19:06] <mr_pouit> sid ;-)
[19:07] <geser> and u-d-t 0.119?
[19:07] <mr_pouit> yep
[19:08] <mr_pouit> I removed .launchpadlib and .cache/lp_credentials, but it doesn't change anything
[19:09] <geser> requestsync got recently upgraded to work with python-launchpadlib 1.9 (ie. let python-launchpadlib handle the authorization completely)
[19:11] <geser> you might ask leonardr (on #launchpad, probably after the weekend) if the code to work with python-launchpadlib 1.9 should also correctly work with 1.8 too (or if we should bump the dependency to >= 1.9)
=== Daviey- is now known as Daviey
=== superm1` is now known as superm1
[19:41] <mr_pouit> geser: I just built python-launchpadlib 1.9 on sid, and it works as expected, so u-d-t 0.119 should  bump the dep
=== WaVeR` is now known as WaVeR
=== james_w` is now known as james_w
=== highvolt1ge is now known as highvoltage
=== Kmos is now known as Guest79780
[20:50] <ari-tczew> DktrKranz: around?
[20:51] <DktrKranz> yeah
[20:53] <ari-tczew> DktrKranz: oh, great. Do you remember what's the point of this change? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/sane-backends-extras/natty/revision/12
[20:54] <DktrKranz> ari-tczew: IIRC, it was to get rid of an old libtool NBS
[20:54] <ari-tczew> DktrKranz: Can I drop it if package builds fine without it?
[20:54] <DktrKranz> 99,9% could go away
[20:56] <ari-tczew> DktrKranz: OK, I'll test build and get you back the information. ;-)
=== popey_ is now known as popey
[20:58] <DktrKranz> :)
[21:05] <ari-tczew> DktrKranz: Built fine. Dropping.
[21:06] <kamal> who can kill a PPA build for me?  (its a kernel targeted to the wrong distro -- hate to have it clog up the builder for hours).
[21:06] <ari-tczew> kamal: ask on #launchpad
[21:06] <kamal> ari-tczew: ty
[21:06] <ari-tczew> kamal: np
[21:07] <paultag> kamal: go to the source of the package detail and request delete
[21:07] <paultag> kamal: I just did the same thing two hours ago
[21:07] <kamal> paultag: I've done that, but the builds are already running, and don't appear to be stopping
[21:07] <paultag> kamal: oh, then it's past the point of no return
[21:07] <ari-tczew> !sru | ubottu
[21:07] <ubottu> ari-tczew: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[21:13] <ari-tczew> !ffe
[21:13] <ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
=== broder_ is now known as broder
[21:56] <ari-tczew> bdrung, tumbleweed, geser: when I entry wrong password while requestsync: http://paste.ubuntu.com/575727/
[21:57] <bdrung> ari-tczew: file a bug
[21:59] <ari-tczew> bdrung: why it now asks me twice for passwords?
[21:59] <ari-tczew> previous requestsync didn't ask and I was happy.
[21:59] <bdrung> ari-tczew: because of heavy changes in launchpadlib
[21:59] <ari-tczew> bdrung: is it possible to workaround?
[22:00] <bdrung> ari-tczew: dunno. you may ask in #launchpad
[22:02] <tumbleweed> ari-tczew: is this from a gnome session?
[22:03] <tumbleweed> see ubuntu-dev-tools' NEWS file
[22:03] <ari-tczew> tumbleweed: nope
[22:04] <tumbleweed> ari-tczew: that bug has been passed upstream to python-keyring, but there are known workarounds (sort-of)
[22:11] <ari-tczew> bdrung: bug 729383
[22:11] <ubottu> Launchpad bug 729383 in ubuntu-dev-tools (Ubuntu) "[requestsync] Traceback when password is wrong" [Undecided,New] https://launchpad.net/bugs/729383
[22:13] <tumbleweed> ari-tczew: what password was wrong?
[22:13] <ari-tczew> tumbleweed: do you want to get to know my password?
[22:14] <tumbleweed> ari-tczew: no, I mean did you get a gnome-keyring password dialog?
[22:15] <ari-tczew> tumbleweed: dunno whether gnome-keyring, but 1st was kwallet and 2nd was pinentry, I guess.
[22:15] <ari-tczew> and I dunno which password it needs.
[22:16] <tumbleweed> ari-tczew: ok, but it works when you get the password right?
[22:18] <tumbleweed> ari-tczew: it'll need your login password (I assume) basically whatever password protects your kwallet
[22:19] <ari-tczew> tumbleweed: I forgot password :/
[22:20] <tumbleweed> ari-tczew: I guess you'll have to delete your kwallet password-store then
[22:20] <ari-tczew> tumbleweed: how?
[22:21] <tumbleweed> it's in ~/.kde/share/apps/kwallet/ according to google
[22:49] <tumbleweed> ari-tczew: just committed the download-specified-version support to pull-{lp,debian}-source we discussed
[22:51] <ari-tczew> tumbleweed: how it works now?
[22:51] <ari-tczew> if I want to get source from snapshot
[22:53] <tumbleweed> ari-tczew: I'll trigger a PPA build
[22:54] <tumbleweed> oh, that's already in the queue
[23:23] <lfaraone> A MOTU just uploaded version 0.3.7-2ubuntu1 of a package I  maintain in Debian. That's fine, except one problem: the latest version in unstable is 0.3.7-1. When I release the *right* 0.3.7-2, how can I ensure that gets moved over to Ubuntu?
[23:26] <paultag> lfaraone: sounds like someone screwed up :(
[23:26] <lfaraone> I'm actually at a loss how the uploader came across the changes I had in VCS which were previously unpublished, the UDD branch for my package only has the released version. (Ubuntu's changelog of pithos now has an "UNRELEASED" entry that its basing on)
[23:26] <paultag> lfaraone: might have to either bump to 3 up or ask for that package to get removed :(
[23:26] <paultag> lfaraone: +1
[23:27] <lfaraone> merde. it was published 21 minutes ago.
[23:27] <lfaraone> too late to get it removed now. <_<;
[23:27] <paultag> lfaraone: at least now you get to yell at the MOTU who did it :)
[23:28] <lfaraone> oooh, he's @canonical.com.
[23:28] <paultag> lfaraone: :D
[23:28] <Ampelbein> lfaraone: pithos?
[23:28] <lfaraone> Ampelbein: yep.
[23:28] <broder> lfaraone: there are other options than uploading a -3. you could upload a -2, and then we could merge it as -2ubuntu2
[23:28] <Ampelbein> lfaraone: I asked in #ubuntu-desktop
[23:28] <broder> (or the always excellent -2ubuntu1reallyjust2)
[23:29] <Ampelbein> lfaraone: ken is in there
[23:29] <lfaraone> Ampelbein: there were no changes in -2, other than including changelog entries that were lost in -1, but I was going to roll out a -2 with the patch Ken just uploaded.
[23:29]  * lfaraone joins and waves.