[00:00] I mean libilmbase-dev knows what's needed to link to it, if you use pkg-config to find out [00:01] I'm *really* confused now... [00:03] Sorry I'm not understanding it all, I am trying to, but sometimes it's a bit _too_ much [00:09] xteejx: basically I'm saying that instead of hardcoding -lHalf into this makefile you should probably add something like $(shell pkg-config --libs IlmBase) [00:09] also I'm telling you that .pc files exist and may help you when you are trying to find your way around libraries you don't know [00:09] tumbleweed: Can I not just add -lHalf to the debian/rules (there is a suitable place for it, and it wouldn't change the main source)? [00:10] I understand the .pc files thing...sort of, well more so than the other stuff :) [00:10] xteejx: yes, we like minimal changes in ubuntu, but you also need to forward something upstream [00:11] Upstream dev I assume? Surely they'd fix it anyway with the new gcc? [00:11] no, if they use a new gcc they'll run into this [00:12] Doesn't that mean they'll fix it anyway, is what I mean? [00:12] Just wondering [00:13] put it this way, do we want to maintain every fix for every bug that we've only discovered in ubuntu? It would quickly become unmanageable, esp in universe where we have little manpower for the size of the archive. We want to ship unmodified source wherever we can. [00:14] Right, so sending these fixes to Deb and dev will help eliminate the need for that I assume? [00:15] I think I understand that now [00:15] yip, try to do that where possible [00:15] (unless it's something that'll never be relevent for them) [00:15] Modifying the source here in Ubuntu and then sending those changes to Deb and dev will remove the need for.... [00:15] will mean that they'll fix it and we can go back to unmodified [00:15] patching rules or whatever when it comes to syncing again? [00:16] Staying closer to Debian, I get it [00:16] well...unmodified, not necessarily Deb [00:17] most of the time, it's debian. And we only auto-sync from debian [00:17] I mean if Deb haven't made changes we're just as equally close to dev version :) [00:19] It seems to be compiling with the change in debian/rules, but that's not in the upstream source :( [00:19] I'll scrollback to the other bit [00:19] I'm guessing CIMG_EXR_LDFLAGS in examples/Makefile [00:20] I did see that when I grepped for LDFLAGS [00:20] I thought we weren't meant to modify the source [00:20] or is that just merges? [00:21] most of the time, we try to fix things inside debian/rules if possible (and yes that's not upstream source). But that's often not possible. [00:22] this package uses source format 3.0 (quilt), so it can take quilt patches [00:22] but ftbfs is different because this would be a problem WITH the source and we'd have to pass the fix to the dev right? [00:23] I'm not entirely sure I understand your question [00:23] xteejx: a lot of things can cause a FTBFS [00:23] when we're fixing ftbfs errors, is it ok to mod the source, I mean like these ones? [00:23] sorry it's late, not making myself clear [00:24] yes. ftbfs is just a class of bug, a nice obvious one [00:24] it's great when packages have good test suites - then they ftbfs when anything goes wrong [00:24] Ok, so the main question is this...why bother with quilt or patching at all? [00:25] xteejx: if you have an easy fix involving debian/rules, use it. [00:25] xteejx: sometimes you need to patch the source, but noot always [00:25] but this is different because the dev will do this anyway with the gcc change? [00:26] xteejx: I was taking you down that route so you can file a bug with upstream with a fix that's good for them. But that doesn't have to be the same fix we use [00:27] Right I see. But of course if we can help them,, we should? [00:27] that's always good - and I'm probably a little more pedantic about that than some of the old-hands [00:27] Or to put it another way.... [00:28] We don't have to, but we do :) [00:28] I think teaching new devs good habits is beneficial [00:28] No, I totally agree [00:28] Best to get in good habits instead of bad old ways [00:29] I've actually just forwarded that basic256 fix to debian, should probably inform the dev too? [00:30] I tend to not bother when I've informed debian - because th edebian maintainer of a package probably has an existing relationship with the upstream. But some packages in debian are pretty neglected. [00:30] I see [00:31] You know, I can't believe how helpful and patient most are here! [00:31] sometimes we aren't :) I'm just busy finishing reading an article before going to bed - and it's taken a little longer than I expected :) [00:32] sorry :) [00:33] heh no problem, just finished it. night. [00:33] tumbleweed: Goodnight, and thank you again :) [00:33] xteejx: that's one of the things I love about this community [00:33] micahg: Definitely! [00:33] Makes a change. Back in my old days with Fedora...nothing, you're on your own [00:34] and I was only a user [00:39] in debian/rules with a ftbfs package I have " override_dh_auto_install: cd examples && $(MAKE) Mlinux "LDFLAGS=-lm -lpthread" " would just adding -lHalf in there be ok or should I make an attempt to fix the source? [00:39] Not sure where to do it if so [00:40] Or remove that from rules and add those flags directly to the source in that file it wants? [00:41] Plus the -lHalf [00:42] Hmm, there's a LOT of LDFLAGS options on the Makefile [00:44] Hmm, think I'll give up for tonight [00:44] Night all [00:44] micahg: Catch ya later :) [01:02] * ajmitch wishes LP had a few more buildds [01:03] ajmitch: they usually do, about 10 buildds are MIA [01:05] yeah I know, just a bit frustrating to have a reported 9 hour queue time when I want a lib built so that its rdepends can be rebuilt :) [01:06] of course I forgot to add the bug # into the changelog, and remembered that about 10 seconds after uploading... [01:06] oh you mean the official buildds... [01:07] yes, the 3 amd64 buildds are all stuck on the same package of course :) [01:08] ajmitch: yeah, those take several hours :( [01:09] oh? are they building firefox? ;) [01:09] openjdk [01:09] even better :) [01:09] kklimonda_: firefox got pushed to -security today :) [01:09] yay, one of them finished 1 minute ago! :) [01:10] ajmitch: and another one takes its place :-/ [01:10] now *another* build of it starts [01:10] * ajmitch should turn to drink for solace... [02:18] bah... if you did a full debuild, is there a way to have dput only upload the source so that lp doesn't reject the whole damn thing because it also includes the binary? [02:19] no, because it's referred to in the gpg-signed .changes file [02:20] does debuild -S really take that long? [02:22] heh, there we go... bzr buiddeb also takes -S ;) [02:22] wasn't sure about that [04:16] Hey MOTU. I'm interesting in packaging up a Ubuntu-local metapackage for Fluxbox ( and some stuff to enable people to use it as a DE ). I started some basic work on it, and it's looking pretty good so far. How hard will it be to get such a package uploaded? [04:17] It would not be a fork or anything, just a few small metapackages to make using flux nice again :) [04:17] If it helps, I'm upstream on Fluxbox in Debian. I can take changes for it up there, so we can keep everything nice [04:21] paultag: take a look at some of the -desktop packages for examples [04:22] micahg, yup. I have that working, and seeds on my people.ubuntu [04:22] micahg, I can package it, I was just wondering about policy [04:22] and logistics and such :) [04:22] paultag: Not hard at all. [04:22] Heyya ScottK :) [04:22] If you upload it to Debian, it'll be automatically sync'ed into Ubuntu. That's easiest. [04:23] ScottK, are the *ubuntu-* packages uploaded to Debian as well? [04:23] not usually [04:23] paultag: Generally we prefer to see new packages maintained in Debian. Is there a reason why it would have to be Ubuntu specific? [04:23] but not never either [04:24] ScottK, I'm not sure. I've not looked into it. I was considering making something like fubuntu-desktop to allow people to install flux + some tools. I have not looked into how much of it is upstream, but I don't see any reason why not, except for branding. I guess branding can be dynamic from the build vendor. [04:25] I think this is worth some more thought on my part [04:25] That way Debian can have the benefit too. [04:25] If that turns out to be problematic, it shouldn't be very difficult to get something like that into Ubuntu directly. [04:25] That's true. [04:26] ScottK, getting through the NEW queue takes months though :( [04:26] Then again, I'm in no hurry [04:26] Not right now. [04:26] For a trivial package like you're talking about, it shouldn't take long. [04:27] Licensing is the hard part of New and for a metapackage it hardly applies. [04:27] True. [04:27] and I guess germinate would work fine upstream [04:27] might have to move off my people.ubuntu and use LP or something [04:28] OK, well thanks for the talk ScottK, lifeless, micahg [04:28] I don't think it matters. [04:28] that helps a lot [04:28] :) === ara_ is now known as ara [08:05] Good morning! :) [08:47] lucidfox: You'd like the keynote at the openSUSEConf here right now. It's a combined one on gnome and kde history. ;) [08:47] Link? [08:48] http://conference.opensuse.org/indico//contributionDisplay.py?contribId=93&confId=0 [08:48] Cornelius is from KDE, Vincent from GNOME [08:48] Hope they'll upload the slides later. [08:48] Unfortunately no recording done here. :/ [08:51] we should offer debconf consulting[tm] [08:52] LOL [08:52] Definitely. No proper speaker mics neither. [08:52] Which limits the possibility for proper talk if you always have to hold a mic. :/ [08:52] do visitors have to pay a conference fee? [08:52] No [08:52] ok, fair enough [08:52] still though... === ara_ is now known as ara === debfx_ is now known as debfx [09:10] shadeslayer, hi [09:11] shadeslayer, there?? [09:17] dholbach: harverst lives!!! \o/ [09:17] :) === hrw|gone is now known as hrw [09:20] :) [09:52] persia, hey i have been able to install maverick using some workarounds. === makl is now known as 16SAAK30G === 16SAAK30G is now known as makl === funkyHat_ is now known as funkyHat [12:50] Afternoon all :) [12:53] I'm looking at the ftbfs for stardict-tools, but can't see where to put the -lz flag [12:54] I've looked in Makefile.*, configure* and debian/rules [13:00] dpkg: error processing /var/cache/apt/archives/libgirepository1.0-dev_0.9.12-0ubuntu1_amd64.deb (--unpack): trying to overwrite '/usr/share/gir-1.0/DBus-1.0.gir', which is also in package gir-repository-dev 0.6.5-6ubuntu9 [13:00] ops, wrong window === ara_ is now known as ara [14:42] does anybody running natty desktop? [14:50] ari-tczew: of course [14:50] tumbleweed: what graphic do you use? [14:53] intel [14:58] tumbleweed: I'm not sure about bump to natty. Is it enough stable to use? [15:00] seems fine to me. It hasn't got unstable yet :) [15:01] (I dual-boot to the previous release on my laptop which I use when the dev release is completely unusable, usually happens for a week or two at some point - specific hardware issues usually) [15:05] ari-tczew: I use natty on intel/4500 laptop and on radeon/hd5xxx desktop [15:07] ok thanks [15:12] don't worry, all the fun X/driver breakage is queued up for upload in pkg-xorg git :) [15:13] Sarvatt: so newer xserver/xdrivers soon? [15:16] on nvidia probably tseliot is working [15:16] hopefully, we had to stick to some really buggy versions in 10.10 (intel especially) because of the release date getting moved up [15:16] I hope for radeon driver with opengl and xvideo for hd5xxx [15:17] Sarvatt: this bug should be fixed - bug 653274 [15:17] Launchpad bug 653274 in linux (Ubuntu) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver" [Undecided,Confirmed] https://launchpad.net/bugs/653274 [15:17] we have the opengl side already [15:17] but we need an updated x-x-v-ati to use it [15:17] theres no released version that works with it yet though [15:18] ari-tczew: i dont see that getting fixed anytime soon without ditching plymouth [15:19] Sarvatt: This is funny, that Canonical can't workaround this problem. [15:26] ari-tczew: what's the problem with nvidia? [15:28] tseliot: probably bug 653274 is related to nvidia software [15:28] Launchpad bug 653274 in linux (Ubuntu) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver" [Undecided,Confirmed] https://launchpad.net/bugs/653274 [15:30] ari-tczew: maybe we no longer use the vga16fb module? [15:31] tseliot: is it a question for me? [15:31] oh I didn't read the bug and assumed it was just another request to make plymouth on the blob look as good as it does with KMS [15:32] ari-tczew: no, I guess cjwatson knows the answer though [15:35] * ari-tczew facepalms [15:40] tseliot: not really my field [15:40] cjwatson: I guess it was Keybuk then [15:41] yes === hrw is now known as hrw|gone [17:08] this simple python script http://pastebin.com/nXWjZMFV gives this error http://pastebin.com/kWS039CP [17:09] is this an error in the lib or is it inside the rdf? [17:10] c_korn: looks like a proble with rdf [17:11] c_korn: similar to bug 660832 [17:11] Yeah, I can reproduce here c_korn [17:11] Launchpad bug 660832 in Launchpad Registry "invalid syntax on team members RDF" [High,Fix committed] https://launchpad.net/bugs/660832 [17:12] ah great, joao already filed a bug for it :) [17:12] then there was an issue in inner team communication :) [17:33] ttx: tomcat6 still ftbfs. IMO due to ant1.7-optional is in universe. [17:33] maybe tomcat6 should be moved to universe [17:35] debfx: nah, serna-free ftbfs! I think that you use 64bit. [17:57] ari-tczew: yeah, I have no idea why it fails though [17:58] * ari-tczew is thinking why are there a lot FTBFS... upstreams or toolchain is wrong? [18:01] toolchain is more strict than before and that hits now upstreams that weren't very strict on conformance [18:26] geser: what is the purpose of get more strict toolchain? [18:27] conform more to the standard [18:28] some things that get used are in the grey area, and those create the "problems" [18:28] i don't know about the ubuntu decision, but in general, you can catch real programming errors if you make your toolchain stricter [18:29] now we will get a huge of FTBFS this cycle [18:29] ari-tczew: we would get them anyway at some point [18:29] ari-tczew, fixing the FTBFS errors makes it better software anyway [18:30] because many didn't notice that they need a symbol from an other library (it worked till now) [18:30] paultag: as long as the fixes get forwarded upstream. :) [18:30] achiang, :) [18:34] paultag: okay, but admins should take into consideration one condition: human resources to fixing FTBFS [18:34] I see that you are pretty optimistic, let's fix some of them. [18:38] ari-tczew, really it's a team effort. Ubuntu is not a fork like most people think about it. Remember, we have all of Ubuntu and Debian. Debian will have to fix these packages eventually, and since they have maintainers on the package, it's really not *that* crazy [18:38] ari-tczew, with DDs working, and Ubuntu MOTU sending patches upstream, it's not going to be that big of a deal [18:40] btw, how does one see the list of FTBFS? [18:40] achiang, http://qa.ubuntuwire.org/ftbfs/ [18:41] a bit over 200 packages [18:41] paultag: thanks [18:41] sure [18:45] let's try to your confidence [18:45] how can I fix this FTBFS? http://paste.ubuntu.com/517580/ [18:48] check in which directory that file is and if the gcc call uses the correct -I value to find it [18:48] (and if the package is in B-D at all) [18:49] geser: I changed two B-D, for newest and existing packages. [18:51] check if perhaps the include path has changed [18:52] ehhh, too much to do, too little time to do [18:52] that's normal, get used to it :) [18:52] Hi all, what is the linker flag for /lib/libz.so.1 is it -lz ? [18:52] yes [18:53] Hmm, I tried that and now I get "/usr/bin/ld: cannot find -lz" [18:53] is zlib1g-dev installed? [18:54] I'm using pbuilder-dist, hmm it's not in the build-deps, that needs updated too :) [18:56] xteejx: did you see you got a hat tip in a Debian changelog already? [18:56] micahg: Yeah I did :D [18:57] * micahg needs to get better at upstreaming patches :-/ [18:57] lol aww [18:57] :) [18:57] fgs this package is terrible, another linker needed !!! [18:58] /usr/lib/X11.so.6 ? -lX11 ? [18:58] does anybody have /etc/apt/sources.list for natty? [18:58] yes [18:58] geser: yes to me [18:58] > [18:58] ? [18:59] xteejx: yes [18:59] :) thanks [18:59] geser: as long as you're here, is the DMB meeting next Monday only going to be 1hr? [18:59] xteejx: the name between "lib" and ".so.*" is what comes after "-l" [18:59] geser: I guessed it was that, just didn't look "right" [19:00] micahg: probably, as many other DMB members are at UDS too, I guess they try to get done in 1hr [19:00] ari-tczew: I used the one from maverick and s/maverick/natty/ [19:02] geser: ok, is there a plan for the people at UDS to meet in person for the meeting? [19:02] I did that in vbox, it worked perfectly fine, substituing maverick for natty [19:02] Had to comment out the "extra" lines [19:03] micahg: I don't know of any. Perhaps ask those who are at UDS (I'm not) [19:03] geser: oh, sorry, I'll check with persia [19:04] micahg: what, you'd like to discuss your application over a beer? ;) [19:04] kklimonda_: heh, at 8 in the morning? [19:05] beer for breakfast :) [19:06] Well its 7pm here so get sending those beers"!!! [19:06] xteejx: I meant the DMB meeting is at 8AM at UDS :) [19:07] micahg: Maybe I just wanted an excuse for a beer :P hehe [19:07] * micahg hands xteejx a beer [19:07] hmm, right - the time difference is going to be my bane on the UDS :/ [19:07] Cheers! [19:07] kklimonda_: I had that in brussels, but it worked in my favor since I'm a night owl :) [19:08] bdrung: ping [19:08] micahg: you can always discuss it over the cereal flakes ;) [19:08] ari-tczew: pong [19:08] micahg: so am I but the 16hrs long flight is probably going to make me into a zombie anyway ;) [19:09] bdrung: what do you think about report to lintian a new warning, where package hasn't wrapped B-D or Depends on d/control? [19:10] lintian reports bugs and violations of debian policy and it's not in policy yet, isn't it? [19:15] bdrung likes wrapped B-D so I'm asking him for this :) [19:18] ScottK: could you unsubscribe bug 470550 from ubuntu-release ? [19:18] Launchpad bug 470550 in coreutils (Ubuntu) "uname -p and uname -i reporting `unknown'" [Low,Triaged] https://launchpad.net/bugs/470550 [19:19] ari-tczew: having a very low priority tag (e.g., pedantic) for too long (> 80 chars) B-D, Depends, ... in d/control would be nice. [19:32] The patch I reported upstream for wwwoffle will be included in the next release! [19:32] Wow, I like seeing that things flow nicely :) [19:34] xteejx: congrats! keep in work :) [19:35] Thanks :D [19:44] hello i am raja sekhar [19:44] i have given my yahoomail id for pgp registration [19:44] but the ymail not having the decryption capability [19:45] so how can i get confirmed [19:45] any one help me please [19:45] i am trying from hours [19:45] any one please [19:45] You don't use yahoo mail to decrypt, you download the mesage and decrypt it with gnupg === jtechidna is now known as JontheEchidna [19:46] xteejx, you mean gnupg in terminal [19:47] Yup [19:47] gnupg


[19:47]  or gnupg  
[19:47]  https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[19:55]  ftbfs fixed bug 664662 woohoo
[19:55]  Launchpad bug 664662 in tea (Ubuntu) "tea FTBFS on natty" [High,Triaged] https://launchpad.net/bugs/664662
[20:00]  xteejx: Good that you have forwarded the fix to debian. In the future, mention clearly on the report by commenting that you also want to get the fix in Ubuntu. Right now, that's not clear since you just subscribed sponsors.
[20:01]  xteejx: Also, whenever you patch a package that uses 3.0 (quilt) format, make sure that there is no debian-changes-* patch that dpkg-source is making
[20:02]  Looking at your debdiff, your changes are in that patch
[20:02]  bilalakhtar: I don't agree with you. I think that it's clear when he has attached debdiff for Ubuntu.
[20:02]  You will need to rename the patch to something sensible
[20:02]  and set the appropriate DEP-3 tags
[20:02]  ari-tczew: That wasn't a strong point of mine, you are right
[20:02]  xteejx: http://dep.debian.net/deps/dep3/
[20:03]  bilalakhtar: do you will take this one for sponsoring?
[20:03]  ari-tczew: Do you want to ? I just did a quick review, you are free to take it
[20:03]  bilalakhtar: I can, when he did a fix for debdiff :P
[20:04]  I have tomorrow very important exam
[20:04]  ari-tczew: but do take care that he makes the changes I mentioned above
[20:04]  ari-tczew: You have an exam tomorrow? I am busy in daily schoolwork nowadays, and so have slowed down in development
[20:05]  bilalakhtar: nationnal exam in logistics.
[20:05]  oh!
[20:06]  okay, /me stops the talk from going too offtopic
[20:07]  * ari-tczew is repeating GS1, EAN and other terms related to bar codes. (supply chain management)
[20:20]  james_w: ping
[20:20]  hi bdrung
[20:21]  james_w: i want to update bzr-builder.
[20:21]  bdrung, in natty?
[20:21]  james_w: yes
[20:21]  great
[20:22]  james_w: can i change the packaging (3.0 (quilt), dh 7)?
[20:23]  and move from lp:~james-w/bzr-builder/packaging to lp:ubuntu/bzr-builder?
[20:23]  morning
[20:24]  Cool! Keybok just ran M-o-M again, and now the number of merges went down from 161 to 143 ~
[20:24]  * ajmitch hopes that squeeze can release before DIF 
[20:25]  bdrung, please feel free to do the latter, and use dh 7, but please stick to v1 for now
[20:25]  james_w: why?
[20:25]  what speaks against 3.0 (quilt)?
[20:25]  bdrung, because bzr-builder doesn't support v3, so it can't be "self-hosting"
[20:26]  ah, ok
[20:26]  james_w: are the maverick branches (i.e. lp:ubuntu/maverick/foo) frozen?
[20:27]  yes
[20:27]  james_w: bzr-builder lacks an "rm" command. would it possible to have a "rm" command that is mapped on "bzr rm"?
[20:27]  james_w: ok, good, I had someone propose a merge and I requested it be proposed against lp:ubuntu/foo instead
[20:27]  bdrung, why do you need it?
[20:28]  james_w: because the run command is not enabled on launchpad (but the rm command would be safe).
[20:28]  james_w: are the -proposed branches auto created on upload, or can I push one?
[20:28]  micahg: it is created when you upload to proposed
[20:29]  bdrung, yeah, I mean why do you need to rm a file
[20:29]  bilalakhtar: that I know, the question is what about before the first upload
[20:29]  micahg, you can't currently push one, they may be working on fixing that in LP right now, I'm not sure
[20:29]  micahg: if it didn't change, you can't push to -proposed if it doesn't exist
[20:29]  james_w: because i want to use lp:ubuntu/ and remove debian/patches
[20:29]  not actively
[20:29]  you can upload to a ppa to create the sourcepackagename
[20:29]  micahg: get all merges proposed to lp:ubuntu/maverick/foo , but I don't think you can create lp:ubuntu/maverick-proposed/* . Not sure, ask james_w
[20:29]  bug #617653
[20:29]  Launchpad bug 617653 in bzr-builder "Please add a rm command" [Undecided,New] https://launchpad.net/bugs/617653
[20:30]  and then push to ubuntu/debian/whatever
[20:30]  lifeless, it's not sourcepackagename
[20:30]  james_w: oh, ok.
[20:30]  lifeless, it's official branches
[20:30]  bdrung, makes sense, please file a bug
[20:30]  james_w: ok, thanks, I'll just upload the package to -proposed and let the importer do its thing
[20:30]  james_w: hmm, not sure where thats at
[20:31]  james_w: bug #617653
[20:31]  Launchpad bug 617653 in bzr-builder "Please add a rm command" [Undecided,New] https://launchpad.net/bugs/617653
[20:31]  lifeless, I don't know if Tim was doing it as part of lp:foo creating and linking
[20:31]  bdrung, excellent, thanks
[20:36]  what is the process to fix a FTBFS? at this point, i've figured out the patch that needs to be written, and verified that it does build in my pbuilder. my question is: is a launchpad bug automatically created for each FTBFS that i can attach my patch to?
[20:37]  if it makes a difference, the package/failure is: https://launchpad.net/ubuntu/+source/fossology/1.2.0-3/+build/1999835
[20:37]  achiang: no, you file the bug if you're working on it
[20:37]  then subscribe ubuntu-sponsors once you have a good patch
[20:38]  s/tested/
[20:38]  micahg: ah, easy enough. thanks.
[20:39]  micahg: should i create a debdiff style patch, with a changelog entry? or do i just create a pure code patch?
[20:39]  achiang: w/changelog entry makes sponsoring easier
[20:39]  micahg: ok, great, thank you
[20:39]  achiang: thank you for helping :)
[20:40]  micahg: yep, my goal is to become a MOTU at some point. :)
[20:40]  achiang: me too :)
[20:42]  achiang: nice to hear that. good luck and have fun!
[20:42]  ari-tczew: thanks!
[20:43]  achiang: well, we wait for your patches to sponsor
[20:52]  bdrung: some time ago we've talked about uploading package automatically through syncpackage. I requested a wish: bug 664719
[20:52]  Launchpad bug 664719 in ubuntu-dev-tools (Ubuntu) "syncpackage should upload files automatically" [Wishlist,New] https://launchpad.net/bugs/664719
[20:53]  it'd be nice to have soyuz do it, rather than having to use these hacks
[20:54]  ajmitch: do you mean about sync-in-launchpad? wgrant said that this is in progress
[20:54]  yes
[20:55]  but probably it won't support field 'sponsored by:' :/
[20:58]  ari-tczew: there could be a form for it
[21:00]  micahg: tell it to LP developers
[21:01]  ari-tczew: I am against uploading the .changes file directly, because I think that the package should be tested before uploaded.
[21:01]  ari-tczew: when they fix the permissions and add the sync button, I'll file a bug :P
[21:04]  is there a variable that controls build concurrency in pbuilder?
[21:07]  ari-tczew: yep, commented on the bug
[21:36]  james_w: does bzr-builder use python-apt?
[21:38]  bdrung, don't think so
[21:38]  bdrung, it uses python-debian which uses python-apt
[21:39]  that was my perception too
[21:50]  xteejx: there is a merge pointed to you in universe - linthesia
[22:58]  Did someone say my name? I was out
[23:15]  Is it a bug that r-cran-base requires libreadline-dev and libreadline6-dev but they conflict?
[23:24]  ari-tczew: What was wrong with bug 664662? I don't underdtand it.
[23:24]  Launchpad bug 664662 in tea (Ubuntu) "tea FTBFS on natty" [High,Incomplete] https://launchpad.net/bugs/664662
[23:51]  xteejx: look at the debdiff, it contains an auto-generated quilt patch. Give the quilt patch a more sensible name, dep3 tag it, and remove all the instructions that it currently has in the header
[23:52]  tumbleweed: I've no idea what that means. I'm currently quilt-ing libs.diff to change the
[23:52]  src.po file in the upstream source, I assume thats it?
[23:53]  xteejx: look at the debdiff - open it in an editor
[23:53]  I have, not sure what i'm looking at
[23:53]  xteejx: you notice that the majority of it is the description of the quilt patch.
[23:53]  it tells you that you should replace it
[23:54]  At the bottom? Yes I see that change is the same one I made in the upstream source to
[23:54]  fix the ftbfs
[23:55]  well, I should hope so, but that's not what I'm talking about.
[23:55]  https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[23:59]  Hmm...still really confused, I can use quilt to make patches that's about it
[23:59]  xteejx: quilt is a system to manage patches against the upstream source