[02:04] <RAOF> @pilot out
[06:18] <Laibsch> I've been trying to recompile thunderbird source in a pbuilder environment and ran into a strange error: http://paste.debian.net/109094/ What is this execvp permission error?
[06:21] <c2tarun> Laibsch: can you paste the ouput of ls -al
[06:22] <c2tarun> Laibsch: pastebin the output of ls -al debian/migrator/
[06:23] <Laibsch> c2tarun: from the source directory or from inside the pbuilder?  source dir: http://paste.debian.net/109095/
[06:24] <c2tarun> Laibsch: actually I want to see ls -al  from inside of debian/migrator
[06:25] <Laibsch> http://paste.debian.net/109096/
[06:25] <Laibsch> there you go
[06:25] <Laibsch> not sure if that is different when pbuilder runs
[06:26]  * Laibsch points to line 61 in http://paste.debian.net/109094/
[06:27] <Laibsch> maybe a path problem with some obscure cc file lying around somewhere?
[06:28] <micahg> Laibsch: are you sure your pbuilder is set up correctly?  although, I can't say I've used pbuilder to test this on lucid, but I believe it works for natty
[06:28] <c2tarun> Laibsch: sorry I got disconnected, you still there?
[06:28] <Laibsch> sure, I'm still here
[06:29] <Laibsch> micahg: that's always a hard question to answer.  If I were aware of any defects, I'd fix them (or at the very least point them out) ;-)
[06:29] <Laibsch> micahg: if you can be more specific, I can have a look
[06:29] <micahg> Laibsch: well, have you tried recreating it from scratch
[06:29] <Laibsch> OK, I'll do that now
[06:30] <micahg> Laibsch: also, which "release" are you trying this in pbuilder for?
[06:33] <Laibsch> lucid host and lucid pbuilder.
[06:36] <micahg> Laibsch: also, you could try logging in and seeing what's actually fails
[06:37] <c2tarun> micahg: can you please help me with this error http://paste.ubuntu.com/573321/ I know how to fix this error, but I dont know where to link the libraries to fix the error.
[06:37] <Laibsch> I'm going to recreate the pbuilder first and see if that works, then.  I know how to log in to a pbuilder to update the system, etc. But I've never logged in to pbuilder with source unpacked.  How does one do that?
[06:38] <micahg> c2tarun: no, sorry
[06:40] <micahg> Laibsch: set it to not clean the environment and login fter the failure
[07:26] <pitti> Good morning
[07:52] <c2tarun> can anyone please help me with this error http://paste.ubuntu.com/573321/ I know how to fix this error, but I dont know where to link the libraries to fix the error.
[07:56] <pitti> c2tarun: you have to add -lkio to barcode_LDADD (or similar) in the Makefile.am
[07:56] <c2tarun> pitti: are you sure about Makefile.am?
[07:57] <pitti> c2tarun: if it's using automake; I don't know at all about cmake, qmake, etc.
[07:57] <pitti> but they certainly must have an equivalent of that
[07:59] <c2tarun> pitti: here is Makefile.am http://paste.ubuntu.com/573348/
[08:00] <pitti> c2tarun: kbarcode/Makefile.am, not the one in the root dir
[08:06] <c2tarun> pitti: it worked thanks :)
[08:07] <c2tarun> pitti: but how did you know which file to change?
[08:07] <pitti> c2tarun: linked libs are always specified in Makefile.am with automake
[08:07] <c2tarun> pitti: hmm.....
[08:07] <pitti> unless they come from pkg-config, of course
[08:08] <dholbach> good morning
[08:08] <c2tarun> pitti: should I use a patch for this change? and can i use the variable LIBS ?
[08:08] <pitti> but even with pkg-config you need to add them there, just not directly with -lname, but with something like $(KIO_LIBS)
[08:09] <pitti> c2tarun: you should send that upstream and have it fixed there as well
[08:09] <pitti> and patch it in the meantime, yes
[08:09] <c2tarun> dholbach: good evening :)
[08:09] <pitti> c2tarun: the variable shouldn't be called "LIBS", it sohuld be kbarcode_LDADD
[08:09] <c2tarun> pitti: thanks :)
[08:10] <c2tarun> pitti: kbarcode_LDADD or KIO_LIBS
[08:10] <dholbach> hi c2tarun
[08:10] <pitti> ah
[08:10] <pitti> c2tarun: those are two differnet things; I just made up KIO_LIBS, I don't know whether it's defined (that's done in configure.ac)
[08:11] <c2tarun> pitti: ok, so finally what should I use? kbarcode_LDADD?
[08:11] <pitti> c2tarun: usually configure.ac slurps in various pkg-config queries to get the required libraries for a particular module like kio, and then you write something like kbarcode_LDADD = $(KIO_LIBS) $(QT_LIBS) ...
[08:12] <pitti> but if you don't have these, then specify them directly with kbarcode_LDADD = -lkio -lqt ...
[08:17] <didrocks> good morning
[08:55] <brendand> hi
[08:56] <brendand> i need to find the url for the rsync server for old-releases
[08:56] <brendand> particularly i want to rsync this image : http://old-releases.ubuntu.com/releases/10.04.1/ubuntu-10.04.1-alternate-i386.iso
[08:56] <StevenK> brendand: Why not 10.04.2?
[09:03] <brendand> StevenK - It's for debugging purposes
[09:04] <c2tarun> pitti: ping
[09:05] <pitti> still here..
[09:06] <c2tarun> pitti: I made that changed and it build succesfully, but dont know why my debdiff is extremely large. How can i show it to you?
[09:06] <Laibsch> c2tarun: try piping it through lsdiff first
[09:07] <Laibsch> you will likely see some changed files that maybe you did not intend to change?
[09:07] <c2tarun> Laibsch: what is lsdiff?
[09:07] <Laibsch> a program
[09:07] <pitti> c2tarun: presumably it caused an autoreconf run
[09:07] <pitti> c2tarun: if you want to minimize it, apply the same change to Makefile.in in your patch
[09:07] <Laibsch> c2tarun: debdiff $dsc1 $dsc2 | lsdiff
[09:07] <pitti> this will avoid calling automake
[09:07] <Laibsch> c2tarun: just try it
[09:07] <StevenK> brendand: Poking around with rsync got me rsync://old-releases.ubuntu.com/old-releases/releases/10.04.1/
[09:07] <pitti> Laibsch, c2tarun: lsdiff doesn't show the actual changes any more
[09:07] <Laibsch> which is a good thing
[09:08] <Laibsch> IMHO
[09:08] <StevenK> brendand: The way I found it was 'rsync rsync://old-releases.ubuntu.com/' which gave me a listing
[09:08] <Laibsch> I only want to know which files a patch touches
[09:08] <janimo> @pilot in
[09:08] <al-maisan> One of my machines seems afflicted with bug #723482; when I try SysRq-i as described in comment #24 I only get to the SysRq HELP string ..
[09:08] <c2tarun> pitti: the biggest entry in debdiff starts with this header http://paste.ubuntu.com/573361/
[09:08] <brendand> SteveK Ah. It's not rsync://rsync. like the other ones
[09:08] <StevenK> brendand: No, but host could have told you that. :-)
[09:09] <Laibsch> al-maisan: try #ubuntu+1 instead
[09:09] <al-maisan> Laibsch: ?
[09:09] <al-maisan> ah
[09:09] <al-maisan> ok
[09:09] <pitti> c2tarun: right, you need to create a proper patch
[09:09] <pitti> don't just modify it inline
[09:11] <c2tarun> I created proper patch, take a look http://paste.ubuntu.com/573362/
[09:12] <c2tarun> pitti: ^^
[09:12] <pitti> c2tarun: "Origin: upstream, http://www.kbarcode.net/
[09:12] <pitti> "
[09:12] <pitti> c2tarun: that's not what Origin: is for; it's for the origin of the patch, which is you
[09:13] <c2tarun> pitti: than what is From for?
[09:13] <pitti> c2tarun: yes, you should drop Origin: from the patch
[09:13] <pitti> c2tarun: and as I said, you either need to apply the change to Makefile.in as well (in your patch), or create a separate 99_autoreconf.patch, etc.
[09:14] <c2tarun> pitti: what do you mean by applying change in Makefile.in as well as in patch? I am not getting.
[09:15] <pitti> c2tarun: I think you really need to read an autotools tutorial at some point..
[09:15] <pitti> c2tarun: if you change Makefile.am, the next package build will re-run automake to update Makefile.in, since it's outdated
[09:15] <c2tarun> pitti: may be I do :( where can I get that?
[09:15] <pitti> c2tarun: so you should also patch Makefile.in for the additional library, so that it is not out of date; this will avoid all the autoreconf noise
[09:17] <c2tarun> pitti: ok, so my patch should modify Makefile.am and Makefile.in. but which file to modify first, as outdation will be checked by time-stamp(I guess)
[09:17] <pitti> c2tarun: usually you can change them both in the same patch
[09:19] <c2tarun> pitti: which file to modify first in patch? I think Makefile.am please correct me if I am wrong
[09:19] <pitti> c2tarun: right
[09:30] <c2tarun> pitti: I made a patch changing both files., but while building the source package it failed.
[09:31] <c2tarun> pitti: here is the patch http://paste.ubuntu.com/573367/
[09:32] <c2tarun> pitti: wait a sec something is wrng
[09:44] <c2tarun> pitti: hey, I am facing one problem with that patch, please reply when you are free.
[09:44] <pitti> c2tarun: the patch looks fine -- what's the problem?
[09:45] <c2tarun> pitti: after building the binary package when I trying to build the source package I am getting the error patch failed.
[09:46] <pitti> c2tarun: did you reapply the patch to a freshly unpackaged source package? if not, then presumably the autogenerated debian-changes-blabla patch and the automatically modified source will conflict
[09:47] <c2tarun> pitti: I pulled completely fresh source package, modified changelog created patch pushed it, made changes, refresh it and then build the binary package.
[09:48] <c2tarun> pitti: then when I tried to build the source package I got the error.
[09:55] <pitti> "the error" == ?
[09:56] <c2tarun> pitti: http://paste.ubuntu.com/573377/
[10:04] <pitti> c2tarun: I suppose building the source package works if you didn't build the binary package yet?
[10:04] <pitti> c2tarun: in general I recommend building the source package first, as binary builds often leave behind cruft
[10:04] <pitti> c2tarun: as I already said, I suppose that the binary build still called automake at some point and thus changed the Makefile.in
[10:06] <c2tarun> pitti: actually I wasn't aware that there is a squence for building the source and binary package. :( I just wanted to test my patch so I build it first. I'll repeat again
[10:08] <Riddell> c2tarun: patching Makefile.in files is a bad idea, those are generated files
[10:09] <c2tarun> Riddell: I have to make a patch to add libraries to Makefile.am what should I do?
[10:09] <pitti> Riddell: I think he tried that first, but then ended up with a huge debian/patches/debian-changes-blabla
[10:10] <c2tarun> Riddell: yup ^^
[10:10] <Riddell> ending up with a huge debian/patches/debian-changes-blabla patch is the easiest way in my experience of autotools, it's not elegant but then neither is autotools
[10:11] <Riddell> that's what we did for kde 3 packages, trying to keep the Makefile.in changes in sync with a patch is just fiddly for no gain
[10:12] <c2tarun> Riddell: so I do upload a debdiff with debian-changes-* patch?
[10:12] <Riddell> that would be my approach yes
[10:12] <c2tarun> Riddell: sure I'll do that
[10:19] <cjwatson> Riddell: nowadays you can use dh-autoreconf
[10:19] <cjwatson> c2tarun: ^-
[10:19] <c2tarun> cjwatson: what is that for?
[10:19] <cjwatson> c2tarun: 'apt-cache show dh-autoreconf' before asking questions ;-)
[10:20] <cjwatson> it solves your problem
[10:22] <c2tarun> cjwatson: ok, I got it, this may solve the problem but I dont know how to use it. (My guess place them in rules file)?
[10:22] <cjwatson> can I suggest reading its documentation
[10:23] <cjwatson> you can run 'man dh-autoreconf' after installing it and you'll get a page explaining how it works
[10:26] <ion> also http://manpages.ubuntu.com/manpages/natty/en/man7/dh-autoreconf.7.html
[10:31] <c2tarun> cjwatson: thanks :) one more question, do I have to add dh-autoreconf into build-depends?
[10:32] <tumbleweed> can a core-dev please open lucid and maverick tasks on bug 623342 for me?
[10:43] <c2tarun> cjwatson: ping
[10:57] <pitti> c2tarun: yes, you need to add dh-autoreconf build-dep
[10:58] <pitti> tumbleweed: done
[11:00] <c2tarun> pitti: here is the rules file http://paste.ubuntu.com/573397/ I added lines 10 and 11 is it correct?
[11:00] <pitti> c2tarun: no, this will convert cdbs to dh
[11:01] <pitti> c2tarun: add an include /usr/share/cdbs/1/rules/autoreconf.mk
[11:02] <c2tarun> pitti: done, anything else I should add?
[11:02] <pitti> should work
[11:03] <c2tarun> pitti: it is building, I didn't understood the stuff we did with rules file, can you please explain me a bit?
[11:04] <cjwatson> c2tarun: FYI if I haven't replied to a question on IRC it's because I'm doing something else - pinging won't help
[11:04] <c2tarun> cjwatson: sorry
[11:06] <joaopinto> mvo, hi, is the lintian check during .deb installs on aptdaemon planned to be enabled on Natty ?
[11:07] <pitti> c2tarun: the main point is to call dh_autoreconf during build; with using cdbs, this is done with what I wrote above; calling dh is incompatible with cdbs (it's a different build system)
[11:08] <cjwatson> pitti: jockey in natty seems to have moved nvidia-common from Recommends to Depends, which breaks architectures other than amd64 and i386
[11:08] <cjwatson> if it has to be Depends, then jockey-common is going to have to be Architecture: any ...
[11:09] <pitti> cjwatson: ah; and we can't do arch specific depends
[11:09] <pitti> cjwatson: I think we can move it back for now, it's not that importnat
[11:09] <cjwatson> you can do arch-specific depends but only with Architecture: any
[11:09] <cjwatson> you'd have to reopen bug 704597 if you moved it back :-/
[11:10] <pitti> we can replace ^ with explicitly seeding it, too
[11:12] <pitti> cjwatson: uploading a fix now
[11:12] <cjwatson> pitti: thanks!
[11:13] <pitti> thanks for pointing out
[11:14] <mvo> joaopinto: is it a problem? we got a lot of crash reports due to nasty debs
[11:14] <pitti> cjwatson: nvidia-common is arch: i386/amd64; if I seed it, I don't need to specify this, as this will ignore nonavailable packages anyway, right?
[11:15] <cjwatson> you don't need to, although it reduces the number of noisy warnings from germinate if you do
[11:15] <pitti> ok, will do then
[11:15] <joaopinto> mvo, at the current state yes, a) it does not provide an override button, b) IMHO it should have been better communicate because it affects many 3rd parties which do not provide nasty debs
[11:18] <mvo> joaopinto: thanks, could you please help me with that by pointing to debs where its doing the wrong thing? this sounds like something worth discussing with glatzor (upstream) and we can figure out how to change it in a way that still catches the nasty ones without affecting the rest
[11:21] <dholbach> janimo, happy patch pilot day
[11:22] <directhex> mvo, blocking on usage of /opt is a huge no-no IMHO. plenty of third-party debs segregate themselves there
[11:22] <janimo> dholbach, happy patch pilot puppetmaster day to you too :)
[11:22] <joaopinto> mvo, thanks, that's already happening at bug 712377 , I am trying to understand if that is a planned feature for Natty
[11:22] <mvo> directhex: indeed, that is a bug
[11:22] <dholbach> :-D
[11:22] <c2tarun> pitti: I got this error, Can you please take a look, http://paste.ubuntu.com/573407/
[11:22] <directhex> mvo, using lintian for the check is cheap, and lintian correctness is rarely the problem. bigger issue is validating anything in pre*/post* which may mangle the system horribly
[11:23] <ion> Ooh, s-c uses lintian. Awesome.
[11:23] <pitti> c2tarun: hm, this usually means that some part of dh_autoreconf failed; do you have the full build log?
[11:24] <mvo> directhex: right, I agree here. still, lintian is a first step (even if its a bit over the top currently)
[11:24] <c2tarun> pitti: yes I have but its quite long, may not be fit for pastebin
[11:25] <mvo> directhex, joaopinto: I think the solution is to pass a list of checks to lintian instead of running them all
[11:27] <directhex> mvo, yeah, that sounds reasonable imho
[11:30] <c2tarun> pitti: how can I show you the build log/
[11:30] <joaopinto> mvo, apart from the improvements maybe someone could write a short summary about the change ? Probably due to the lack of information I have already seen some comments about eventual Canonical interference
[11:30] <pitti> c2tarun: pastebin should work
[11:32] <mvo> joaopinto: that sounds reasonable, I can blog about it
[11:32] <joaopinto> great :)
[11:32] <c2tarun> pitti: this is how much I got, 1000 lines approx http://paste.ubuntu.com/573411/
[11:33] <mvo> joaopinto: cheers
[11:33] <pitti> c2tarun: please check the start of the build log whehre it calls dh_autoreconf, and check if it has errors
[11:36] <c2tarun> pitti: its very messy :( my terminal only giving me 1000 lines when I tried to rebuild it I got this error http://paste.ubuntu.com/573412/
[11:37] <zyga> I have a PPA for for lucid, I want one library from maverick, I can bzr get lp:ubuntu/maverick/sourcepackagename and then dpkg-buildpackage -S, but that will leave my package unsigned, should I just hack-add myself to Uploaders or is there a better way to do this?
[11:38] <zyga> my goal is to be able to dput ppa:zkrynicki/myppaname *.dsc of the package I want to "backport" from maverick to my lucid ppa
[11:40] <zyga> doko_, ^^ ?
[11:53]  * zyga just added a changelog entry and ~zyga1 to version so that a normal package can be built
[11:54] <doko_> zyga: debsign -k should work
[11:55] <zyga> doko_, so it's best not to add another changelog entry and just sign with my own key instead?
[11:55] <zyga> doko_, and push that to a PPA?
[11:56] <doko_> no extra changelog entry required, but ~zyga1 works too
[11:57] <zyga> ok, thanks
[12:47] <kirkland> i can't seem to adjust my date/time settings from the date/time menu in unity
[12:47] <kirkland> can anyone help me with that?
[12:52] <chrisccoulson> mdz - can you remember what you were upgrading when you got bug 724202?
[13:04] <mdz> chrisccoulson, I don't think so, but I can't check timestamps at the moment as that computer is on another continent
[13:11] <hunger> How long dues bzr take to checkout bzr?
[13:11] <hunger> Sorry, wrong channel.
[13:12] <ev> mterry: might I ask you put on your MIR hat and have a look at https://launchpad.net/bugs/726453 ? I mistakenly thought dpkg-repack was already in main, and it's a dependency of some installer stuff I'd like to land.
[13:13] <mterry> ev, ok
[13:14] <ev> thanks
[13:16] <soren> ev: What do you need dpkg-repack for? (Just curious)
[13:18] <ev> soren: http://bazaar.launchpad.net/~mvo/+junk/apt-clone/view/head:/apt_clone.py
[13:21] <mterry> ev, approved
[13:21] <ev> mterry: thanks bunches
[13:21] <mvo> ev: I adress the points you raised last friday today, the msg is not lost :)
[13:22] <soren> ev: Oh, I see. Thanks.
[13:22] <ev> mvo: oh, brilliant.  Thanks a lot!
[13:22] <ev> soren: sure thing
[13:32] <hallyn> jbernard: the upstart script seems to be working for libcgroup.  I'm not sure how you want to handle the cgroup mountpoint (keep it always at /mnt, use /sys/fs/cgroup for maverick and natty, use something else).  Do you mind if I hand bug 644669 over to you?
[13:52] <janimo> @pilot out
[14:02] <siretart> doko_: would it be possible to copy sun-java6 from maverick/partner to natty/partner?
[14:03] <doko_> siretart: I don't have partner upload rights anymore. will forward the request
[14:03] <siretart> doko_: thanks
[14:04] <siretart> I've added natty to our fai infrastructure here, and so far this is the only issue in our 'error.log' :-)
[14:04] <siretart> unity still doesn't work though, but I need to debug that further
[14:07] <mterry> cjwatson, could you please add libappindicator to desktop set?
[14:08] <cjwatson> mterry: done
[14:09] <mterry> cjwatson, thank you!
[14:17] <zyga> how can I list valid options to debhelper --buildsystem=?
[14:18] <cjwatson> zyga: 'dh_auto_configure -l' in a source tree
[14:19] <zyga> thanks, I needed python_distutils
[14:38] <janimo> any known issues with cowbuilder-dist on natty? create and update works but a build does not, complaining about pbuilder-satisfydepends-dummy
[15:25]  * ogra grins about the changelog of cjwatson's recent upload 
[15:25] <ogra> unknown (unknown1) unknown; urgency=unknown
[15:26] <highvoltage> I guess that was not to the archives
[15:26] <ogra> its a mis-entry that apparently was in debian
[15:27] <ogra> between biosdevname 0.3.1 and 0.3.3
[15:28] <cjwatson> it was from the upstream changelog - I didn't want to redact it
[15:29] <ogra> yeah
[15:29] <ogra> just found it funny
[15:29] <cjwatson> it was actually a missing header line
[15:29] <cjwatson> dpkg-genchanges or something made up the line you quoted
[15:29] <ogra> ah, i didnt kno wit is that clever
[15:29] <cjwatson> kees: does your comment in bug 723870 indicate approval of the MIR once biosdevname is available?
[15:40] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in #ubuntu-classroom in 20 minutes!
[15:45] <pitti> tseliot: thanks a lot for adding the ABIs to nv/fglrx!
[15:46] <zumbi> someone knows what is going on with gobby.ubuntu.com, I cannot log into it, is it a problem on my side or is the server down?
[15:47] <ogra> zumbi, works fine here
[15:49] <zumbi> ogra: maybe you could email me the Emdebian/ docs?
[15:49] <ogra> zumbi, sure, no prob
[15:51] <zumbi> thanks
[15:53] <ogra> zumbi, sent
[16:02] <tseliot> pitti: np ;)
[16:06] <zumbi> ogra: got it! thanks
[16:06] <ogra> :)
[16:21] <ogra> pitti, can we do something against jockey-common not being installable on armel due to nvidia-common being nonexistent
[16:21] <pitti> ogra: yes, fixed this morning
[16:21] <ogra> hmm
[16:21] <cjwatson> beat you to it ogra ;-)
[16:22] <ogra> heh
[16:23]  * ogra should apt-get update his chroots before asking 
[16:23] <ogra> works fine
[16:24] <cr3> anyone happen to know where the revision number of a pci device is supposed to be stored in sysfs?
[16:31] <pitti> cr3: I don't think it is; I think you need to use libpci to find out
[16:32] <cr3> pitti: thanks for the tip, I'll have a look there
[16:34] <amitk> unity noobie question: how does one start an application not on the dock? Search doesn't seem to work...
[16:35] <pitti> amitk: it works here (if it doesn't crash..); what's the app you are looking for?
[16:35] <amitk> pitti: mumble (or any other really). Currently I start it the terminal and then tell unity to keep it in the launcher
[16:36] <amitk> unoptimal
[16:37] <amitk> IIUC, clicking on the Ubuntu logo in top left and typing in the search box should do magic, somewhat like Apple's spotlight?
[16:39] <charlie-tca> amitk: I navigate to /usr/share/applications and use the files there when nothing else seems to work
[16:39] <amitk> charlie-tca: eeekkk!! It's a brave new world :)
[16:39] <pitti> amitk: hm, works here; but that only really started to work a few days ago, are you running current natty?
[16:40] <pitti> amitk: before that, ctrl+alt+t and launch from there :)
[16:40] <amitk> pitti: up to date as of a few minutes ago, but using unity for the first time since nvidia binary became available today
[16:40] <amitk> ok, so terminal it is then :)
[16:41] <artfwo> mterry, is it okay to ask you about your latest libappindicator package here?
[16:43] <amitk> nice, 35Mb crash report (compiz) for launchpad to gulp down :)
[16:45] <ogra> we love details :)
[16:45] <amitk> pitti: so apport dialog says "Report Problem", "Restart Program". What if I want to do both?
[16:46] <amitk> ogra: I'm just hoping that it isn't processing my ubuntuone and dropbox folders :)
[16:46] <ogra> lol
[16:47]  * ogra pulls amitk's crash report for some new music
[16:48] <Daviey> cjwatson / pitti / kees / sabdfl  : I sent a mail to the TB last week, is it still in moderation?
[16:48] <cjwatson> probably, I'll look now
[16:48] <Daviey> oh, or mdz
[16:48]  * amitk adds output from /dev/random to the crash report to introduce ogra to a new genre
[16:48] <Daviey> cjwatson, thanks
[16:49] <ogra> LOL
[16:50] <mdz> Daviey, if it's the one you sent last Thursday, it went through
[16:50] <mdz> I saw it over the weekend
[16:51] <mdz> Daviey, regarding bind9?
[16:51] <Daviey> mdz, ah yes, thassim
[16:51] <Daviey> Thanks.
[16:51] <cjwatson> yep, I've just flushed the moderation queue and it wasn't there
[16:51] <amitk> compiz really doesn't like a HUP signal
[16:51] <Daviey> thanks cjwatson
[17:10] <till_> hi
[17:11] <kshadeslayer> till_: hi :)
[17:11] <till_> i'm building a package and i keep my 'debian/' dir in a git repository. so whenever i debuild, i have to copy my debian/ dir into the source dir of my package. i tried symlinking it but then debuild complains. is there a way to make it work so i don't go crazy? ;)
[17:12] <raphink> till_, have you considered git-buildpackage?
[17:12] <raphink> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
[17:12] <till_> raphink: i have not! i just figured out the rest, i'd really just like to symlink the folder though
[17:13] <raphink> I don't think that's possible, but git-buildpackage probably provides similar solutions
[17:18] <natschil> Hello. I am trying to write a multitouch virtual driver that gets some input from somewhere and then translates this into multi-touch input to the kernel. What apis do I have available to pass this on to the kernel?
[17:19] <natschil> this would only need to work in ubuntu. Preferrably 10.10 but 11.04 is ok too.
[17:19] <oubiwann> natschil: you should join #ubuntu-touch and re-ask that question
[17:20] <natschil> oubiwann: oh cool, I didn't know that existed. will do.
[17:20] <oubiwann> natschil: no prob! I mention it because that's where the experts are hanging out, not here ;-)
[17:29] <mterry> artfwo, yeah, what's up about libappindicator?
[17:32] <artfwo> mterry, I meant to ask about uploading a change to ubuntu-desktop branch, but figured it out already
[17:33] <pitti> amitk: you can't right now, I'm afraid
[17:33] <pitti> Daviey: I did a moderation run  few hours ago, should be here now
[17:33] <mterry> artfwo, k, cool
[17:33] <mterry> @pilot in
[17:34] <Daviey> pitti, yup, thanks
[17:34] <artfwo> mterry, take a look at bug 724917 if you have time
[17:34] <artfwo> I've prepared an upstream merge proposal and a package merge, 'cause upstream didn't review the change for several days already
[17:34] <seb128> artfwo, mterry: kenvandine is on it, I've pinged him about that on #ubuntu-desktop a bit earlier
[17:35] <mterry> seb128, k, cool.  kenvandine: i'm on patch duty, can gladly take that if you're busy
[17:35] <seb128> artfwo, several days already", you filed that on saturday and upstream is working on it during it paid job time
[17:36] <kenvandine> mterry, if you can, please do
[17:36] <kenvandine> debugging datetime atm
[17:36] <seb128> artfwo, it's just monday morning in the u.s
[17:36] <mterry> kenvandine, hopefully nothing I did with my preference dialog
[17:36] <kenvandine> nope
[17:36] <artfwo> seb128, understood it indeed
[17:36] <kenvandine> mterry, it isn't showing events in the right order, so pretty easy to missing something important :)
[17:37] <mterry> artfwo, k, I'm looking now
[17:37] <kenvandine> thx mterry
[17:37] <seb128> kenvandine, seems it's showing recurrent events first then others
[17:37] <kenvandine> yeah
[17:43] <mterry> artfwo, how'd you generate the new .defs file?  by hand?
[17:43] <artfwo> mterry, yes, but I checked it later against h2defs output
[17:46] <artfwo> mterry, the new .defs is fully compliant with appindicator.h, and once built, fixes all the python indicators' crashes
[17:46] <mterry> artfwo, yeah, looks right, just confirming one thing manually
[17:47] <amitk> pitti: its kinda required for things like compiz that don't have an icon i can click on to restart.
[17:48] <kees> cjwatson: biosdevname> yes
[17:48] <kees> cjwatson: I looked through the package out of the NEW queue
[17:49] <cjwatson> ok, cool, thanks - if somebody wants to push that through binary NEW then, I can promote it
[17:49] <pitti> cjwatson: want me to review?
[17:52] <cjwatson> yes please
[17:54] <pitti> cjwatson: do you have the MIR bug # handy? (so that I can close it)
[17:55] <soreau> ev: I am in a live session trying to install natty and I patched in http://paste.ubuntu.com/572185/ but it's still just sitting there with busy cursor after clicking forward
[17:59] <cjwatson> pitti: bug 723870
[18:00] <pitti> cjwatson: NEWed, promoted, bug closed
[18:00] <cjwatson> soreau: try patching in http://bazaar.launchpad.net/~ubuntu-core-dev/partman-auto/ubuntu/revision/595 (with appropriate filename adjustments) too
[18:00] <cjwatson> pitti: yay, thank you
[18:00] <pitti> cjwatson: not relevant for MIR, but I noticed that the udev rules do ACTION!="add", GOTO end
[18:01] <pitti> cjwatson: coudl that be an issue with coldplugging, i. e. if the action is "change"?
[18:01] <cjwatson> pitti: would you want to set NAME on action==change?
[18:02] <pitti> it would be wrong in general, I just wonder about the initial udevadm trigger during boot, after initramfs
[18:02] <pitti> ah, ignore me, we do --action=add there
[18:04] <mterry> artfwo, pushed, thanks so much!
[18:04] <artfwo> mterry, thanks!
[18:06] <artfwo> mterry, got a couple of minutes to explain why a) your upload was in ~ubuntu-desktop branch, and b) should I propose merges upstream or in ubuntu in the future?
[18:07] <soreau> cjwatson: It still 'hangs' and there's no output from ubiquity in the terminal
[18:07] <cjwatson> did you reboot after the previous test?
[18:07] <soreau> no
[18:07] <mterry> artfwo, sure.  I'm not a member of the upstream team.  But I am a member of the Desktop team that tries to make sure the package in Ubuntu is in good shape
[18:07] <mterry> artfwo, so while I couldn't approve the merge for upstream
[18:07] <cjwatson> I wouldn't recommend attempting to rerun ubiquity without rebooting after it's fallen over in a heap
[18:07] <mterry> artfwo, I could approve the merge for Ubuntu
[18:07] <soreau> cjwatson: ok
[18:08] <artfwo> mterry, got it, thanks
[18:08] <mterry> artfwo, in future, you did right thing.  It should always be sent to upstream.  Whether you bother to create a separate merge request for Ubuntu just depends on how urgently you want it in
[18:08] <mterry> artfwo, so you did the right thing here
[18:09] <artfwo> mterry, does the ubuntu branch matter here? (lp:ubuntu or lp:~ubuntu-desktop I mean)
[18:10] <artfwo> mterry, i.e. I want my fix in ubuntu ASAP, and what's the right ubuntu branch, if there are many?
[18:10] <mterry> artfwo, so since the package has the Vcs-Bzr field in its debian/control file pointing at lp:~ubuntu-desktop, it indicates that the packaging is handled in a non-typical place (i.e. not lp:ubuntu)
[18:11] <mterry> artfwo, so ~ubuntu-desktop was the right place, because historically, that's where the Desktop team maintains lots of packages (this behavior predates the whole lp:ubuntu thing)
[18:11] <mterry> artfwo, when in doubt, the command 'debcheckout' will check for Vcs-Bzr and give you that if it exists
[18:11] <artfwo> mterry, I see it now, thanks so much!
[18:12] <mterry> yw
[18:48] <till_> raphink: so i checked out git-buildpackage, but i'm not sure how to integrate it into my workflow. right now my biggest 'problem' is that i have to keep the 'debian/' dir inside the source in sync with the actual i have a in git repository. is there a jumpstart guide?
[18:48] <soreau> cjwatson: I couldn't get it to work. It gets stuck on the screen that checks if your connection is working and asks to install 3rd party software. Then I press forward and it sits on busy cursor forever or until I click quit
[19:37] <bryce_> ev, cjwatson, bug #714829 is suitable for your attention.  The issue is a serious OOM situation caused by ubiquity during LiveCD that ends up crashing X.  (Thus, we're getting tons of reports of this issue).  I've posted a patch that reverts a recent ubiquity change and is seen to stop the OOM occurring, but it needs further analysis by one of you two to find a real fix.
[19:38] <cjwatson> good timing, I was just preparing a ubiquity upload
[19:39] <cjwatson> bryce_: what do you think of Mario's later patch?
[19:41] <bryce_> cjwatson, I think it probably can't hurt, but sounds like you'd want both patches
[19:41] <cjwatson> and then we reopen bug 693300, yes?
[19:41] <cjwatson> (whch I agree is less serious)
[19:41] <bryce_> cjwatson, that's right
[19:42] <bryce_> fwiw, the original patch to that bug looks sort of like a sledgehammer solution (screen isn't updating?  let's update it ALL THE TIME) ;-)
[19:42] <cjwatson> OK, I'll go ahead with that since nobody seems to have any better ideas in the short term
[19:42] <bryce_> ok cool, thanks
[20:16] <mterry> cjwatson, can you also add ubuntuone-control-panel to the ubuntu-desktop set?
[20:20] <cjwatson> mterry: done
[20:21] <mterry> cjwatson, thanks!
[20:27] <psusi> ScottK: found question about package qt-sdk.  Links to a bug report you filed asking for the amd64 binary to be removed from the archive, which seems to have been an error.  original question at https://bugs.launchpad.net/ubuntu/+source/qt-sdk/+bug/618075
[20:27] <psusi> iirc, Architecutre: all means it should be built for all archs, as opposed to Architecture: any, meaning the results are architecture independant, is that correct?
[20:28] <ScottK> Yes, but the old arch any binaries were still there.
[20:28] <psusi> err, that was the removal bug, original question was https://answers.launchpad.net/ubuntu/+source/qt-sdk/+question/147275
[20:28] <psusi> that's because it is targeted to arch: all
[20:29] <psusi> so now there is only the i386 build in the archive
[20:30] <psusi> at least according to http://launchpadlibrarian.net/53715084/qt-sdk_2ubuntu2_i386.changes
[20:30] <cjwatson> psusi: you have it backwards.
[20:31] <psusi> hrm... then what's wrong with this package?  according to the build log, it was only built for i386, which generated a _all, but it seems to have only been put in the i386 archive?
[20:31] <ScottK>  qt-sdk |   2ubuntu2 | maverick/universe | source, all is what's in the archive.
[20:32] <ScottK> You are misunderstanding how arch all packages work.  It's as it should be.
[20:37] <psusi> ScottK: it isn't though since the binary is only found in the archive for i386.  Users of amd64 can't install it.
[20:39] <ScottK> I'm not sure what you mean.
[20:39] <ScottK> http://archive.ubuntu.com/ubuntu/pool/universe/q/qt-sdk/
[20:41] <slangasek> ScottK: he's right, actually; somehow the package isn't published in the amd64 Packages file
[20:41] <psusi> lp lists only the i386 build, and qt-sdk does not appear in Contents-amd64.gz.  https://launchpad.net/ubuntu/+source/qt-sdk
[20:41] <ScottK> slangasek: Oh.  Weird.
[20:42] <slangasek> in fact, it's only published on i386
[20:42] <ScottK> Is a no change upload the easiest fix for that?
[20:42] <slangasek> it's correctly published for lucid, so it must have been a publisher bug in the maverick timeframe
[20:42] <slangasek> ScottK: yep
[20:42] <psusi> probably
[20:42] <ScottK> I'll take care of it.
[20:42] <ScottK> psusi: Thanks for bringing it up.
[20:43] <psusi> no problem... kinda curious how it got weirded like that now though
[20:43] <psusi> like, shouldn't the lp page say it was built for arch: all, not i386?
[20:43] <ScottK> Should.
[20:43] <slangasek> which lp page?
[20:44] <psusi> https://launchpad.net/ubuntu/+source/qt-sdk
[20:44] <slangasek> https://launchpad.net/ubuntu/+source/qt-sdk/2ubuntu2 correctly shows the i386 build, which is the build that outputs the arch: all package
[20:45] <psusi> so that is normal?  you  build for i386, and get an _all instead of _i386?  which should be added to the contents of the other archs automatically?
[20:45] <psusi> I figured it would say it built it for the all arch, rather than i386 ( and got a result for all instead )
[20:45] <slangasek> https://launchpad.net/ubuntu/maverick/amd64/qt-sdk/ shows the disappearance of the binary from amd64
[20:45] <slangasek> ScottK: ^^ you did it ;)
[20:46] <ScottK> IIRC it was a leftover amd64 binary or something.
[20:46] <slangasek> psusi: yes, that's normal and correct.  That's the i386 build which can result in packages of arch: i386 and/or arch: all;
[20:46] <slangasek> that page is the wrong place to look to see which architecture a given package is
[20:47] <slangasek> ScottK: ok - in general the arch: all package should smoothly supersede an arch: any package of the same name in the archive
[20:47] <slangasek> so maybe there was an underlying bug here
[20:47] <ScottK> I don't recall why I thought it didn't.
[20:48] <psusi> it looks like this package has always been an arch: all
[20:49] <psusi> so there should never have been an _amd64?
[20:49] <psusi> unless it was there before karmic and lp just doesn't show it...
[20:51] <cjwatson> I suspect somebody processed that removal after the arch: all-ness had already been applied.
[20:51] <cjwatson> I have a feeling that regrettably lp-remove-package.py doesn't catch that.
[21:16] <smoser> cjwatson, If i were interested in putting a static entry into grub menu, would you recommend just packaging a file in '/etc/grub.d/XX_cloud' ? or is there a better way.
[21:17] <slangasek> didrocks: hi, why is unity getting a dependency on libnux-0.9-0 (<< 0.9.28)?  If nux is changing its ABI, that should be reflected in the package name...
[21:17] <didrocks> slangasek: nux is not near ABI or API stable
[21:17] <didrocks> slangasek: basically, it's broken every week
[21:17] <slangasek> didrocks: so this is a convenience to avoid going through NEW each time?
[21:17] <didrocks> that's why we force everyweek latest nux and latest unity
[21:18] <slangasek> didrocks: will it be ABI-stable by beta?
[21:18] <didrocks> slangasek: hoping so, better to discuss with the dx team about it
[21:18] <slangasek> hmm
[21:23] <cjwatson> smoser: that sounds fine
[21:24] <smoser> you have a suggestion on the 'XX' ?
[21:25] <cjwatson> no, pick it however you want the order to fall
[21:45] <cnd> Riddell, I'm looking at the upload of qt4-x11
[21:45] <cnd> the difference you pushed is the one we determined to be incorrect :)
[21:47] <jelmer> hmm, in http://reports.qa.ubuntu.com/reports/sponsoring/, how is "Origin" determined?
[21:50] <james_w> jelmer, using packagesets somehow I think
[21:53] <mterry> @pilot out
[22:12] <Riddell> cnd: oh foo, really?
[22:13] <cnd> Riddell, yeah, you're casting a double * to a float * on arm
[22:13] <cnd> which means that when you advance the variable using values++
[22:13] <cnd> you're only advancing 4 bytes instead of the requried 8 bytes
[22:13] <cnd> all that needs to change is to make the values variable a double * instead of a qreal *
[22:14] <cnd> no casting necessary :)
[22:16] <Riddell> cnd: http://bazaar.launchpad.net/~kubuntu-members/qt/ubuntu/revision/153 ok?
[22:16] <cnd> Riddell, yep!
[22:17] <Riddell> cnd: ok uploading, sorry for the hassle, well spotted
[22:17] <cnd> Riddell, np
[22:17] <cnd> thanks for working with me on it :)
[22:34] <slangasek> pitti: hi, cjwatson suggests that Friday (i.e., immediately after a3) is better for dpkg-multiarch than to land it right now; would you be ok with this?
[22:35] <cjwatson> pitti: this is mainly because we're currently 25 minutes from when skaet wants alpha-3 freeze to start and it seems to me to be cutting it pretty fine
[22:38] <slangasek> is it?  I thought skaet_ wrote that the freeze started 23.5h ago
[22:40] <ogra> i understood she said 23:00 UTC
[22:41] <cjwatson> what ogra said
[22:41] <slangasek> yes, the mail said 2300 UTC on 2/27
[22:41] <cjwatson> blink
[22:41] <ogra> heh
[22:41] <cjwatson> OK, that's not what I thought skaet and I had agreed
[22:41] <ogra> and not how she sounded in -release
[22:41] <xrdodrx> the gnome-paint package is broken
[22:41] <slangasek> a typo in the mail seems possible - I was just going by the mail though :)
[22:42] <xrdodrx> it's 0.3-2
[22:42] <xrdodrx> had to install 0.4
[22:42] <xrdodrx> from https://launchpad.net/gnome-paint
[22:42] <slangasek> cjwatson: the mail is why I was asking at all; if we're not actually /frozen/ yet, I can certainly get it done :-)
[22:42] <xrdodrx> I seem to run in to a lot of broken pkgs on ubuntu
[22:42] <broder> slangasek: whoa....dpkg-multiarch is actually landing in natty? *awesome*
[22:42] <xrdodrx> So far this, beep, and gnibbles
[22:42] <slangasek> broder: subject to the ongoing negotiations with the release team ;)
[22:42] <broder> hehe
[22:43] <cjwatson> backlog of -release was clearly for 2300 on Monday
[22:43] <slangasek> cjwatson: so I actually have 15 minutes to get this done? :-)
[22:43] <ogra> 17 even :)
[22:44] <cjwatson> this is my understanding, but you get to apologise to skaet and clean up if it goes wrong ...
[22:44] <slangasek> yep
[22:44] <Ampelbein> xrdodrx: the current version of gnome-paint in maverick (ubuntu 10.10) is 0.3-2, in natty (ubuntu 11.04, not released yet) the version is 0.4
[22:45] <cjwatson> xrdodrx: well, all those packages install fine here on natty (this is #ubuntu-devel, support for older releases would be on-topic on some other channel)
[22:45] <xrdodrx> Ampelbein, yeah, I fixed it by finding an updated deb...it just bothers me how packages are broken :<
[22:45] <xrdodrx> cjwatson, this is #ubuntu-development, no?
[22:45] <xrdodrx> or am i missing something
[22:45] <Ampelbein> xrdodrx: it isn't broken.
[22:45] <cjwatson> xrdodrx: where we work on the next release
[22:46] <cjwatson> xrdodrx: it's not a bug reporting channel, though - IRC doesn't make a good medium for tracking bugs
[22:46] <xrdodrx> Ampelbein, just because it launches doesn't mean it's not broken
[22:46] <cjwatson> it's a channel for developers to coordinate among themselves and discuss problems
[22:46] <xrdodrx> and gnibbles is broken, so is beep
[22:46] <cjwatson> but we can't take bug reports here
[22:46] <xrdodrx> oh, ok
[22:46] <xrdodrx> sorry cjwatson
[22:46] <cjwatson> the flow would be impossible
[22:46] <cjwatson> np
[22:46] <xrdodrx> I thought this was a place to report because of -devel :<
[22:46] <cjwatson> https://help.ubuntu.com/community/ReportingBugs
[22:48] <cjwatson> uninstallable or non-functional packages would be one reason for us to do stable updates, so it's certainly worth reporting that kind of thing even if it's fixed in natty
[22:49] <xrdodrx> cjwatson, yeah, I've found unaddressed bug reports for each of these packages...guess I'll just wait for natty as it's coming in April :)
[22:51] <cjwatson> I certainly don't mean to discourage you from reporting bugs (quite the opposite), just steering you towards a more effective place to do it :)
[22:51]  * cjwatson -> bed
[23:08] <ari-tczew> jdstrand: * debian/control: update Vcs for natty <- it doesn't need to be mentioned in d/changelog
[23:09] <micahg> ari-tczew: no, VCs changes should be mentioned
[23:09] <micahg> Vcs
[23:09] <jdstrand> ari-tczew: I like to document everything
[23:09] <jdstrand> I changed from trunk to its own tree
[23:10] <micahg> if every package had a uniform Vcs-* in Ubuntu, it would be a different story (like update-maintainer in theory)
[23:11] <ari-tczew> micahg: cjwatson told me that doesn't because d/changelog should include only informations which can't be dropped till sync. vcs can be dropped for sync, so it's not necessary in d/changelog
[23:11] <jdstrand> ari-tczew: that one cannot be dropped for sync
[23:12]  * ari-tczew hopes that cjwatson will answer for it to jdstrand and micahg cause ari-tczew is not going to be unreliable.
[23:12] <jdstrand> ari-tczew: Debian uses ufw-debian, natty has ufw-natty, trunk was ufw-trunk
[23:12] <ari-tczew> jdstrand: I see source name just 'ufw'.
[23:13] <jdstrand> actually, I did use ufw-debian
[23:13] <jdstrand> ari-tczew: I am talking about the Vcs branch name
[23:14] <ari-tczew> jdstrand: and you will keep this change if it's only remaining change
[23:14] <ari-tczew> ?
[23:14] <jdstrand> ari-tczew: that wasn't the case here. if I sync from debian, I'd drop everything
[23:15] <jdstrand> ari-tczew: I am not saying you are wrong, I am saying that I haven't seen policy stating that I shouldn't include it in my merges
[23:16] <jdstrand> ari-tczew: I maintain this package in both Debian and Ubuntu, and it is a way for me to keep my sanity
[23:17] <ScottK> ari-tczew: I think that where someone is doing all the work on a package in Debian and Ubuntu they have a great deal of freedom to do it in  a way that suites their work.
[23:17] <ari-tczew> jdstrand: sorry, I can't give you a link to policy which I was talking about, maybe cjwatson will give you tomorrow.
[23:17] <ari-tczew> ScottK: does it mean that I can;t say anything?
[23:18] <ScottK> ari-tczew: No, but their may be more productive uses of your time than nit picking other people's work.
[23:19] <xrdodrx> can someone test the packages gnibbles in natty for me?
[23:19] <xrdodrx> I don't have the time to install a vm atm :<
[23:19] <cody-somerville> That being said, peer review and the discussions it can produce are usually quite valuable to all parties involved. :)
[23:20] <ari-tczew> ScottK: It's not nitpick. I just say it because I was poked for it in the past and I remember it was in official policy.
[23:21] <ari-tczew> And I guess I'm not that strict as micahg.