[03:13] <nigelb_> james_w`: ping?
[03:13] <james_w`> hi nigelb_
[03:13] <nigelb_> \o/
[03:14] <nigelb_> james_w`: just letting you know that its our month for package training :)
[03:14] <nigelb_> I managed to get one class, though we need a few more
[03:14] <ajmitch> nigelb_: what do you plan to teach us?
[03:14] <james_w`> nigelb_: nice, thanks :-)
[03:15] <nigelb_> ajmitch: I plan to find people who can teach us :p
[03:15] <nigelb_> subtle difference
[03:25] <james_w`> nigelb: I'm can give a session on something, which is how I usually reduce my workload when it is my turn :-)
[03:30] <nigelb> james_w`: \o/
[03:30] <nigelb> james_w`: emmet has agreed too done and I need to poke maco again
[03:31] <nigelb> so, one more and we've filled the schedule except for 9th Sep
[03:31] <james_w`> you rock
[03:31] <nigelb> :)
[03:31] <james_w`> that's tomorrow
[03:31] <persia> How badly do you need one today?
[03:31] <persia> depends where you are :)
[03:31] <nigelb> (its today for me)
[03:32] <nigelb> persia: If you can do one or find somone to do it, I owe you big time ;)
[03:32] <james_w`> oh yeah :-)
[03:33] <persia> If you've a bundle of clamouring students, I'll spend an hour documenting something, but I'd rather not plan a proper session that would be unattended.
[03:33] <persia> Alternately, I'd be more than glad to spend an hour doing Q&A on "How can I review Debian RC bugs to make sure they are closed in Maverick?"
[03:33] <nigelb> tumble weed's session had very poor attendance, so I'm not sure about bundle of students :(
[03:34] <persia> Yeah.  Generally students like advance notice, so they can plan the time :)
[03:36] <nigelb> Since we have 5 Thursday's this month, we'll just take an off today :p
[03:36] <ajmitch> persia: you actually use the rcbugs page?
[03:37] <nigelb> Precisely why we need that class :p
[03:37] <persia> ajmitch, Sadly, only about 6 weeks a year, but during those six weeks, very much so.
[03:37] <persia> Basically, once we hit final freeze, I try to spend time closing as many of them as possible, as we *know* those are critical issues.
[03:38] <persia> (plus it typically smooths the FFe process when one can point at an RC bug in Debian showing why it's important)
[03:38] <ajmitch> persia: right, I've been meaning to get to it asap, I checked that it's looking at maverick now & that there aren't many comments yet
[03:40]  * ajmitch did manage to break it the other day, too
[03:41] <persia> break it?  How?
[03:43] <ajmitch> because the quick & dirty code that I had for multiple ubuntu releases wasn't very robust
[07:17] <robert_ancell> StevenK, do you know about bug 251709?
[08:02] <StevenK> robert_ancell: Only vaguely. What about it?
[08:08] <glatzor> tkamppeter, morning. Is there a way to map packages to printer drivers in Ubuntu yet? I was just looking at the sessioninstaller bug and was wondering if there have been some changes recently.
[08:08] <glatzor> tkamppeter, https://bugs.edge.launchpad.net/ubuntu/+source/sessioninstaller/+bug/612140f sessioninstaller
[08:09] <robert_ancell> StevenK, I think you applied the path initially.  It looks like the patch causes a lot of problems and a lot of people are asking it to be removed.  I'm not sure if it's trading one set of problems for another though
[08:11] <StevenK> robert_ancell: I didn't even write the patch, I just sponsored it. Since then I've not had time to investigate.
[08:12] <tkamppeter> glatzor, no, Red Hat's idea to add tags based on each supported printer device ID to Red Hat's RPM is not yet ported to DEB. AFAIK it not even reached RPM upstream yet.
[08:15] <sabdfl> update-initramfs: Generating /boot/initrd.img-2.6.35-20-generic
[08:15] <sabdfl> .: 6: Can't open /scripts/casper-functions
[08:15] <sabdfl> but will it blend?
[08:15] <sabdfl> s/blend/boot/?
[08:15] <glatzor> tkamppeter, so it would be best to disable the call to PackageKit in the gnome print manager
[08:18] <tkamppeter> glatzor, if the patch fixes session-installer to at least not trigger Apport it is OK, the unneeded PackageKit call does not need significant time. Not patching s-c-p now avoids the risk of regression and keeps the deviation to upstream lower.
[08:25] <tkamppeter> OdyX, hi
[08:26] <tkamppeter> Hi, can someone upload my fixed Jockey package? I have fixed bug 574396 and bug 604698. The fixes are important to support manufacturer-supplied printer drivers.
[08:39] <wzssyqa> can somebody help to rebuild ibus-sunpinyin?
[08:40] <persia> In what way do you need help?
[08:41] <wzssyqa> persia: it is FTBFS because of lack of dep, now it can build sucessfully
[08:42] <wzssyqa> persia: https://edge.launchpad.net/ubuntu/+source/ibus-sunpinyin/2.0.2-0ubuntu1
[08:44] <persia> wzssyqa, Oh, heh.  Then certainly this is the place to ask.
[08:44] <persia> The way such a thing is usually requested is "Could someone please give-back ibus-sunpinyin on all architectures?"
[08:44] <persia> I've just done so.
[08:44] <wzssyqa> persia: i see
[08:45] <wzssyqa> persia: i have wait for it several days.....
[08:59] <robert_ancell> slangasek, I'm looking at the differences between our version of cdrdao, you have listed "Add armv7l target" but I can
[08:59] <robert_ancell> 't fine any change for that
[08:59] <slangasek> robert_ancell: that's not me who listed this
[09:00] <slangasek> robert_ancell: it may be that this was a no-change rebuild with the toolchain targeting armv7 by default; but perhaps you want to check with JamieBennett to be sure
[09:01] <robert_ancell> slangasek, ok, thanks.  I'm guessing it's nothing, because there doesn't seem to be any delta
[09:01] <persia> Made more confusing because there's no matching prior changelog entry to which that might refer.
[09:03] <robert_ancell> ah, I found it - it's one of those confusing packages that has a modified source tarball.  I'll convert it into a patch
[09:47] <amitk> seb128: who is the best person to update powertop with a patch?
[09:48] <seb128> amitk, not sure, pitti? he will be back monday if that can wait
[09:48] <cjwatson> sabdfl: hm, I thought we'd fixed all the bugs of that form.  can you  fgrep -r '. /scripts/casper-functions' /usr/share/initramfs-tools  to find out where that is?
[09:49] <cjwatson> sabdfl: (it probably will boot if that was the only error, but even so!)
[09:52] <amitk> seb128: ok, we can wait till monday, thanks
[09:53] <ogra> amitk, do we have a wikipage or something about the kernel options that need to be enabled for powertop to work ? i'd like to have it working in the ubuntu kernels
[09:54] <ogra> (and i know that iotop and powertop moaned for me in the past about missing kernel features)
[09:55] <amitk> ogra: there isn't an explicity page I know of, but the patch that we're trying to push to ubuntu should make powertop work on omap HW
[09:55] <ogra> ah, k
[09:55] <amitk> and others implementing cpufreq and cpuidle
[09:56] <ogra> i hope it applies on omap4 too :)
[09:56] <amitk> the other options should already be enabled
[09:56] <amitk> ogra: it will since they use the same PM arch, but we can't verify since we don't have omap4 HW
[09:56] <amitk> you can try it from amitarora's ppa though
[09:56] <ogra> we dont have PM enabled on omap4 yet
[09:57] <sabdfl> cjwatson: /usr/share/initramfs-tools/scripts/casper-bottom/46disable_census:. /scripts/casper-functions
[09:57] <ogra> HW lacks full support yet
[09:57] <sabdfl> and thanks for the reassurance :)
[09:57] <tkamppeter> glatzor, mvo, the patch in bug 612140 did not help. It only reveals another problem.
[10:00] <cjwatson> sabdfl: what does 'dpkg -S /usr/share/initramfs-tools/scripts/casper-bottom/46disable_census' say?  I don't have that file here
[10:01] <cjwatson> actually I can probably check the archive for that ...
[10:01] <cjwatson> doesn't seem to be in the archive
[10:02] <cjwatson> sabdfl: if you could put a copy of that file somewhere, I can advise on fixing it in-place
[10:03] <Laney> it's that canonical-census thing
[10:04] <cjwatson> ah, it's in partner
[10:04] <cjwatson> yep, that's the breakage I expected
[10:05] <cjwatson> sabdfl: move the '. /scripts/casper-functions' line down to below the 'esac', and rerun 'update-initramfs -u'
[10:05] <cjwatson> and poke pitti :-)
[10:24] <ricotz> seb128, i have an updated cairo 1.10.0-1ubuntu1 package in my staging ppa, perhaps you can have a look later when everything is up again
[10:25] <seb128> ricotz, I was going to upload that when launchpad is back
[10:26] <seb128> ricotz, thanks for your work, you might want to be on #ubuntu-desktop or tell people before starting changes
[10:26] <seb128> ricotz, it seems you often duplicate work we are doing
[10:27] <glatzor> tkamppeter, ups. I will have a look at it
[10:40] <sabdfl> thanks colin!
[11:39] <tkamppeter> glatzor, mvo, next session-installer bug reported: bug 633913.
[11:51] <tkamppeter> Anyone can upload Jockey for me?
[11:59] <didrocks> cjwatson: thanks for the sync
[12:27] <luboss> hello
[12:28] <luboss> I'm not sure where to ask. I think this is the right place
[12:30] <luboss> I'm very curious how ubuntu devs generate Packages index files in repository from deb packages. I know there is dpkg-scanpackages, but this is somehow very trivial. Another less used tool is apt-move but this doesn't seem to do the right job either.
[12:32] <persia> luboss, This isn't a bad place, but it won't necessarily get you the best answer.
[12:32] <persia> The short answer is that we don't: we rely on the Soyuz component of launchpad to do it for us.
[12:33] <persia> The longer answer is buried in the Soyuz source.  That said, many of us use a wide variety of techniques for short-term, personal, or other archives.
[12:33] <persia> Someone in #launchpad might be able to give a more detailed answer.
[12:34]  * ogra_cmpc thinks apt-ftparchive is the current tool of choice for local archives
[12:34] <ogra_cmpc> (though i'm personally using dpkg-scanpackage too for that task)
[12:35] <penguin42> is there anyway to update an ia32-libs in a ppa?   The 'source' is I think just a big tar of bins which makes it awkward
[12:37] <persia> penguin42, It's the same as one would do anywhere: it's kinda bandwidth intensive.
[12:37] <persia> I haven't looked into it in detail, but it may well be possible to use the new recipe build feature to have launchpad do that automatically daily or something.
[12:38] <penguin42> recipe build ?
[12:38] <luboss> thank you both persia and ogra_cmpc, I will study those
[12:39] <persia> penguin42, http://blog.launchpad.net/cool-new-stuff/launchpads-build-farm-improvements but you may find more from asking the LP folks
[12:39] <penguin42> Thanks
[13:23] <JohnHeikkila> hello
[13:59] <kenvandine> cjwatson, i have another gwibber upload in lucid-proposed that needs accepting, but it is from a re-opened bug which ubuntu-sru is already subscribed
[13:59] <kenvandine> cjwatson, can you please look at it?
[14:00] <kenvandine> cjwatson, it fixes a pretty significant bug which will likely also reduce the number of requests gwibber makes to facebook, so hopefully getting us back down below our allocation
[14:05] <doko> cjwatson: could you promote https://edge.launchpad.net/ubuntu/+source/openjdk-6b18/6b18-1.8.1-2ubuntu1/+build/1950520 ?
[14:05] <doko> or do I have to seed it?
[14:07] <cjwatson> kenvandine: done
[14:07] <kenvandine> cjwatson, bug 595265
[14:07] <kenvandine> thx
[14:07] <kenvandine> :)
[14:07] <kenvandine> you rock!
[14:07] <kenvandine> man i hope that helps with the allocation!
[14:07] <kenvandine> so many people keep just giving work arounds that really don't help... they just get lucky
[14:08] <tkamppeter> Anyone can help me on a package dependencies/upgrade problem (bug 633987)?
[14:10] <cjwatson> doko: that's fine, component-mismatches lists it (once I fixed it, anyway - the web page is mostly blank right now)
[14:10] <cjwatson> doko: promoted
[14:10] <doko> cjwatson: thanks, the arm assembler interpreter wasn't ready for maverick
[14:10] <doko> in b20
[14:11] <cjwatson> I had to peer at madison-lite output for a bit before I worked out what was going on, yes :)
[14:15] <primes2h> g. afternoon ara
[14:15] <ara> hey primes2h
[14:17] <primes2h> ara: I'm testing Ubuntu One... Do they changed the way to sign in in U1?
[14:17] <primes2h> http://testcases.qa.ubuntu.com/Applications/UbuntuOne#Ubuntu%20One%20existing%20user,%20initial%20setup
[14:18] <primes2h> now it appears a window, no Browser anymore.
[14:18] <ara> yes, you are right. in that window you get a link to "manage account"?
[14:18] <primes2h> s/do/did
[14:18] <primes2h> s/changed/change
[14:19] <primes2h> I think testcase should be updated.. Could I?
[14:20] <ara> sure, go ahead
[14:21] <tkamppeter> Hi, can someone upload my fixed Jockey package? I have fixed bug 574396 and bug 604698. The fixes are important to support manufacturer-supplied printer drivers.
[14:23]  * penguin42 is looking at a bootchart trying to understand a ~30 second boot hang my maverick box has gained
[14:24] <penguin42> it looks like the only non-sleeping thing for those 30 seconds is lvm  - which is sleeping on io
[14:26] <sabdfl> tkamppeter: are there any issues in a recent cups that are causing widespread "printer warning" blockages?
[14:27] <sabdfl> clan and my printer stopped working recently, i want to know if i should dig into it or just wait for another update :)
[15:00] <dobey> could i get someone to poke at https://bugs.edge.launchpad.net/ubuntu/+source/pyinotify/+bug/633405 ? :)
[15:56] <ricotz> seb128, ok, sorry about the duplication
[15:57] <seb128> ricotz, no worry
[16:33] <manjo> cjwatson, thanks for all the hard work you put in to make 10.10 install on UEFI based system. I was able to install the x64 desktop image on my intel weybridge, intel will show case Ubuntu running on UEFI based system at the IDF next week.
[16:34] <manjo> superm1, ^
[16:37] <tkamppeter> OdyX, hi
[16:40] <tkamppeter> sabdfl, I do not know about such "printer warning" blockages?
[16:41] <tkamppeter> sabdfl, can you tell me more? Which printer do you have? What exactly happened? What did you try to print? Are there bug reports?
[16:42] <cjwatson> manjo: fantastic
[16:43] <cjwatson> manjo: thanks for all the testing thus far
[16:43] <manjo> cjwatson, ++beer
[16:48] <superm1> manjo, ooh great to hear.
[16:49] <mdz> mvo, if you're around, I think tkamppeter would appreciate some apt guidance in bug 633987
[16:54] <mvo> mdz: thanks, I have a look, I am debugging a software-center issue currently but I can check it out after that
[16:55] <tkamppeter> mvo, mdz, I have explained in the bug what I want to have and with which measures I tried to get it. Probably for most people it actually works.
[16:56] <james_w> didrocks: found the cause
[16:56] <didrocks> james_w: really? great!
[16:57] <james_w> didrocks: it's the rename handling again
[16:58] <didrocks> james_w: urgh, any way to bypass it?
[16:59] <james_w> didrocks: I'm trying to figure out a fix. If it's not easy I can do a terrible hack to make it work in this one case
[16:59] <didrocks> james_w: take your time, still fixing other things and testing
[16:59] <james_w> great
[17:02] <sabdfl> tkamppeter: pebkac
[17:02] <mdz> tkamppeter, there's nothing too unusual about my system; I perhaps have a few extra packages installed
[17:03] <sabdfl> i changed the dhcp settings, both of our printers had been setup with fixed ip address configs
[17:03] <mdz> tkamppeter, the only package on my system which depends on foomatic-db is ubuntu-desktop
[17:03] <mdz> so I would expect this problem to affect others as well
[17:03] <ScottK> Affected me too.
[17:04] <sabdfl> tkamppeter: do you know why autodetected printers would use fixed ip addresses rather than avahi ones?
[17:05] <seb128> tkamppeter, mvo, that's what aptitude says
[17:05] <seb128> The following packages have unmet dependencies:
[17:05] <seb128>   foomatic-db-compressed-ppds: Conflicts: foomatic-db but 20100906-0ubuntu1 is installed.
[17:05] <seb128>                                Conflicts: foomatic-db-hpijs which is a virtual package.
[17:05] <tkamppeter> mdz, what should happen is that ubuntu-desktop gets replaced by the new version which depends on foomatic-db-compressed-ppds instead and the conflict would make foomatic-db uninstalled.
[17:06] <mdz> tkamppeter, yes, I would expect that too
[17:06] <seb128> ubuntu-desktop depends on foomatic-db
[17:06] <tkamppeter> sabdfl, susyem-config-printer usually prefers Avahi-based URIs.
[17:07] <mdz> seb128, ahh, well spotted
[17:07] <mdz> seb128, oh, no, that's the old version
[17:07] <mdz> 1.204 depends on foomatic-db, 1.205 depends on foomatic-db-compressed-ppds
[17:07] <seb128> let me try to apt-get update
[17:07] <seb128> I did upgrade yesterday evening
[17:07] <mdz> so the correct solution is to remove foomatic-db, install foomatic-db-compressed-ppds, and upgrade ubuntu-desktop
[17:08] <mdz> but apt decides to hold back ubuntu-desktop instead
[17:08] <tkamppeter> sabdfl, which printer model do you ghave? Which is the dnssd-based URI and which the fixed-IP-based one?
[17:08] <mvo> probably because of rdpends on foomatic-db
[17:08] <mdz> mvo, a test removal found no other reverse deps on my system
[17:08] <mdz> there could be recommends or suggests but no other depends
[17:09] <tkamppeter> mdz, mvo, do I perhaps need a versioned dependency somewhere?
[17:09] <ScottK> I think you need a transitional package.
[17:09] <cjwatson> my untested suspicion is that your conflicts are overly *strict*
[17:09] <cjwatson> and that weakening to breaks might help
[17:09] <cjwatson> it's a pain to test this kind of thing
[17:09] <cjwatson> having to leave foomatic-db in the archive for other purposes probably doesn't help
[17:10] <cjwatson> ScottK: tkamppeter said a few days back that foomatic-db was still needed for build-dependencies
[17:10] <cjwatson> I didn't catch the details
[17:10] <seb128> $ grep-available -s Package -F Recommends foomatic-db
[17:10] <seb128> Package: foo2zjs
[17:10] <seb128> Package: foomatic-filters
[17:10] <seb128> Package: min12xxw
[17:10] <tkamppeter> ScottK, with a transitional package I have the problem that I do not want to remove foomatic-db from the distro, it will continue to exist but only be used as build dependency.
[17:10] <ScottK> OK
[17:11] <sabdfl> tkamppeter: Xerox Workcenter 6400X
[17:11] <sabdfl> adding a printer with system-config-printer, i see two detections of the same printer
[17:12] <sabdfl> one is "AppSocket/JetDirect network printer via DNS-SD"
[17:12] <sabdfl> the other is Host: 192.168.1.10 Port 9100
[17:13] <tkamppeter> seb128, in foomatic-filters (4.0.5-0ubuntu3) I have already removed the Recommends
[17:13] <sabdfl> interestingly, they both have an IP address in brackets in the selctbox
[17:14] <sabdfl> one is correct, the other is a 169.254.84.167, which I don't recognise
[17:15] <tkamppeter> seb128, in min12xxw (0.0.9-3ubuntu3) foomatic-db is only recommended as alternative if foomatic-db-compressed-ppds is not there.
[17:15] <seb128> ok so dunno
[17:16] <cjwatson> 169.254.0.0/16 is avahi
[17:16] <tkamppeter> sabdfl, which of the two is selected by default?
[17:17] <SpamapS> It might make sense to filter out 169*'s with identical MAC addresses to routable IP's
[17:17] <SpamapS> Just means it got broadcasted while the printer was still negotiating an IP with the DHCP server most likely
[17:18] <SpamapS> or maybe the printer retains its' 169.254 address to allow communication with devices that don't receive an IP
[17:18] <tkamppeter> seb128, foo2zjs (20100728-0ubuntu1) recommends only foomatic-db-engine, not foomatic-db.
[17:19] <cjwatson> somebody should try -o Debug::pkgProblemResolver=true on a failing machine
[17:38] <cjwatson> mvo: hmm, it seems confusing to be using quilt in apt-xapian-index, given that it's a native package?
[17:39] <mvo> cjwatson: feel free to drop it, I don't mind much. I was using it to organize the patches better, but upstream (enrico) is usually quick to apply them anyway
[17:41] <cjwatson> yeah, mostly looking at bug 267330
[17:41] <enrico> mvo: which reminds me to remind you, apt-xapian-index it's in collab-maint :)
[17:41] <cjwatson> I certainly see some obvious places where pitti's fix was incomplete
[17:41] <cjwatson> as it happens I was going to work on that bug in collab-maint ;-)
[17:43] <mvo> enrico: oh, thanks. I'm probably too cautious
[17:50] <neeraj> Hi, I was creating patch using quilt and then I had make changes in various Makefile.am and configure.ac file. Now, the problem is that I can make all changes in these using quilt edit, but I am not sure how the autorunconf file will be called while applying patch.
[17:51] <Riddell> ogra: where's your ARM build failure chart?
[17:52] <ogra_cmpc> chart ?
[17:52] <ogra_cmpc> oh, the table ... one sec
[17:53] <ogra_cmpc> Riddell, http://qa.ubuntuwire.org/ftbfs/
[17:53]  * neeraj got dc again. Not sure whether his query was answered or not.
[17:54] <cjwatson> neeraj: run autoreconf inside 'quilt shell' (you might want to make a separate patch just for that, and remove junk like autom4te.cache before exiting the shell)
[17:55] <Riddell> ogra_cmpc: thanks.  it's looking good
[17:56] <ogra_cmpc> Riddell, well, there is koffice still
[17:58] <neeraj> cjwatson: ok thanks. Trying that.
[17:58] <manusheel> cjwatson: Thanks for the pointers.
[18:02] <cjwatson> enrico: does http://paste.ubuntu.com/491108/ look OK?  this matches a fix already in plugins/apttags.py
[18:03] <cjwatson> enrico: if you don't mind, I can roll a 0.40 with that
[18:04] <enrico> cjwatson: it looks good
[18:05] <enrico> cjwatson: if you're in a hurry you can roll a 0.40. If you're not in a hurry, there's [...]
[18:05] <enrico> cjwatson: #595916 and #594675 to which I have to dedicate an afternoon
[18:06] <enrico> cjwatson: but it won't be this week or the next one, I fear, so feel free to do 0.40
[18:06] <cjwatson> hmm.  I'll have a look at those but may not know the code well enough
[18:06] <james_w> didrocks: I think I've got it
[18:06] <cjwatson> thanks
[18:10] <didrocks> kaoh, great!
[18:10] <didrocks> james_w: great :)
[18:13] <SpamapS> when using bzr-buildpackage with 3.0 quilt format packages, is there a way for it to generate the "xxxver changes" patches and commit those on debcommit?
[18:14] <SpamapS> that would be a pretty awesome feature actually. :)
[18:15] <enrico> cjwatson: #595916 looks like a Xapian python API change (should ping ojwb)
[18:15] <enrico> cjwatson: #594675 is a tricky one that requires laying out a migration path, which I do have in mind already, let's write it to the BTS
[18:16] <cjwatson> I think I'm probably best just getting the immediate job done for now, then
[18:16] <enrico> cjwatson: ok
[18:19] <didrocks> james_w: do you have a patch I can test?
[18:19] <james_w> didrocks: just polishing and committing
[18:19] <didrocks> james_w: great, thanks!
[18:24] <james_w> didrocks: tip of bzr-builddeb should work for you now
[18:24] <didrocks> james_w: grabbing it, should I set some PYTHONPATH and such?
[18:24] <james_w> didrocks: you can use BZR_PLUGINS_AT to run it from an arbitrary directory
[18:25] <didrocks> james_w: trying that
[18:25] <superm1> manjo, okay mine got fully installed too, so just need to figure out those nx problems
[18:25] <james_w> BZR_PLUGINS_AT=builddeb@/tmp/builddeb bzr mu ...
[18:25] <james_w> something like that
[18:25] <manjo> superm1, great news, cheers to cjwatson ... yep ack on NX
[18:25] <cjwatson> superm1: huh, wasn't that the one that wouldn't boot?
[18:26] <cjwatson> superm1: did you use noexec to work around it or something?
[18:26] <superm1> cjwatson, i've got both a 6410 and 6510 - noexec works on the 6510, not the 6410
[18:26] <cjwatson> superm1: right, I tried noexec on mine and it made no difference.  docking station is due to arrive in a couple of days, I think ...
[18:27] <james_w> didrocks: there's a test failure, which isn't a good sign, but it's in a case completely unrelated to yours, so you should be ok for this one branch. I'll work on the failure after lunch.
[18:27] <didrocks> james_w: worked wonderfully well, thanks :)
[18:28] <superm1> cjwatson, cool.  if you'd like me to do any other instrumentation with mine in the interim, i'll be glad to
[18:28]  * didrocks now building unity-place-applications
[18:28] <didrocks> james_w: thanks for working on it so quickly!
[18:49] <neeraj> for running autogen.sh function using quilt, will $quilt shell aclocal, $quilt shell autoconf, $quilt shell automake --add-missing and quilt shell rm -rf autom4te.cache is sufficient?
[18:50] <cjwatson> you should use 'autoreconf -i' rather than running all those by hand
[18:51] <cjwatson> and I'd recommend running 'quilt shell', running successive commands at the shell prompt it gives you, and then exiting that shell
[18:51] <cjwatson> if there's already an autogen.sh in the package, use that rather than autoreconf
[18:56] <neeraj> Ok. there is not autogen.sh, should I add quilt shell autoreconf -i \
[18:56] <neeraj> > && rm -rf autom4te.cache
[18:56] <cjwatson> run quilt shell
[18:56] <cjwatson> press enter
[18:56] <cjwatson> run the commands
[18:56] <cjwatson> type exit, then press enter
[18:57] <cjwatson> (the above will include autom4te.cache in the patch because && is scoped wrongly)
[19:00] <neeraj> cjwatson: ok :)
[19:00] <SpamapS> hmm.. can dh_autoreconf run an autogen.sh ?
[19:01] <SpamapS> yes.. apparently it can
[19:01] <SpamapS> you don't have to use quilt for autoreconf'ing it seems
[19:08] <neeraj> hmm.. sorry for my ignorance  but can you please elaborate? Do i have to make changes in some file or run dh_autoreconf?
[19:10] <juliank> neeraj: Use dh_autoreconf as documented in dh-autoreconf(7)
[19:13] <neeraj> ok. in the quilt files, there alocal.m4. I guess I had to remove it?
[19:13]  * neeraj don't want to redo all steps from scratch. Can he run quilt shell and add rm -rf ?
[19:16] <neeraj> ok. may be I don't..
[19:37] <manjo> superm1, do U have that pastebin of the panic ?
[19:37] <superm1> manjo, http://paste.ubuntu.com/486907/
[19:38] <manjo> superm1, thanks, on the intel weybridge with UEFI 2.1 NX support Active, we are able to boot and64 kernel normally
[19:54] <kenvandine> cjwatson, do you have any tips on how to get around this error:
[19:54] <kenvandine> dpkg-source failed for libdbusmenu_0.3.13-0ubuntu1.dsc [return: 29]
[19:55] <kenvandine> tried on multiple boxes, both lucid and maverick
[19:55] <kenvandine> can't get a source package that can be extracted with dpkg-source
[19:56] <kenvandine> tedg can't either
[19:57] <smoser> Keybuk, around ?
[19:58] <smoser> i'm wondering the difference between 'optional' and 'nobootwait' to mountall.
[19:58] <smoser> i can't think of an expected difference between them if the device was not present at boot.
[19:59] <smoser> anyone know ?
[20:01] <mneptok> is it possible to use btrfs for /boot in Maverick (yet)?
[20:03] <smoser> i think is see the difference now. optional will still hold up boot.
[22:07] <cr3> is it more common for a project to have the directory doc/example (singular) or doc/examples (plural)?
[22:11] <mdeslaur> cr3: a quick non-scientific study of my /usr/share/doc directory says examples is more popular, 275 vs. 12
[22:12] <cr3> mdeslaur: I've also found section 12.6 in the debian policy manual: http://www.debian.org/doc/debian-policy/ch-docs.html
[22:12] <cr3> mdeslaur: "Any examples (configurations, source files, whatever), should be installed in a directory /usr/share/doc/package/examples."
[22:12] <mdeslaur> cr3: well, there you go...unless you only have one single example...then what? :)
[22:12] <cr3> mdeslaur: my project doesn't necessarily need to map to debian packaging policy, I might as well use that as a policy
[22:52] <achiang> what is the proper way to update a package to a new upstream release when autotools are involved? (specifically, i'm looking at libx11)
[22:52] <achiang> i was thinking of: untar upstream.tar.gz, cp -a oldver/debian upstream/  and then see what happens from there...
[22:53] <achiang> oh, except after unpacking upstream.tar.gz, it won't have the autotools artifacts
[22:54] <achiang> oops, i meant to ask that in #ubuntu-packaging
[23:41] <zyga-gone> lucas, ping
[23:46] <manjo> why can't I name my machine with I install maverick ? or am I missing something ?
[23:47] <manjo> I don't see a box where I can enter system name
[23:47] <manjo> Maverick seems to set the system name based on my user name ... for example manjo-laptop
[23:48] <penguin42> manjo: Older ones used to give you that as a default during the install screen as you filled it in but let you change it - is that no longe rthe case?
[23:49] <manjo> penguin42, you man change it after the install ?
[23:49] <penguin42> manjo: No, during - on lucid and previous as you typed in the username on a fiield below it it filled in the hostname box and you could edit it
[23:49] <manjo> penguin42, I want to set the system name when I enter my user name etc ... like I did in lucid...
[23:50] <theGuest> manjo, bug 628087
[23:50] <manjo> yep it does not let me in Maverick... unless I am missing something
[23:50] <manjo> theGuest, thanks .. did not want to open a dup in that case
[23:53] <manjo> design team is making my head ache :)
[23:55] <manjo> I have 3 machines at home, now eachone will be called manjo-laptop... what a PITA