[17:49] <dobey> how do i figure out why adt-run is hanging when i try to run autopilot tests with it?
[18:36] <dobey> elopio: come back to the dark side. we miss you
[18:37] <elopio> dobey: heh, I miss you too :)
[18:37] <elopio> dobey: adt-run -d -s gives more information and lets you log into the testbed after it times out.
[18:38] <dobey> elopio: it doesn't get far enough for that i don't think
[18:38] <dobey> Services restarted successfully.
[18:39] <dobey> that's the last message printed, where it hangs
[18:39] <dobey> it never times out
[18:39] <dobey> that's with a vivid image
[18:39] <elopio> dobey: paste the output you get with -d.
[18:39] <dobey> i can't run with a utopic image, because utopic is eol :-/
[18:40] <elopio> if it doesn't time out, sounds like something bad in autopkgtest.
[18:40] <dobey> and i can't create a wily image. it seems to just hang
[18:41] <dobey> and i don't know how to create an ubuntu-rtm image
[18:42] <dobey> yeah, -d doesn't show anything additional there
[18:42] <dobey> top shows qemu is doing stuff, but no messages on console
[18:46] <dobey> :(
[18:49] <elopio> dobey: with the snappy ssh script, if you pass -b it prints the vm boot console.
[18:49] <elopio> not sure what test bed you are using.
[18:49] <dobey> i'm trying to run the pay-ui click autopilot tests with adt-run
[18:50] <dobey> qemu has a serial console socket, but i'm not sure how to connect to it
[18:50] <dobey> but i can't seem to open it with tail or minicom
[18:50] <dobey> minicom: cannot open /tmp/adt-virt-qemu.9bhk7o7g/ttyS1: No such device or address
[18:50] <dobey> meh
[18:57] <elopio> dobey: for qemu, the option is --show-boot
[18:58] <dobey> option to what?
[19:03] <elopio> dobey: to redirect the vm boot messages to your terminal. adt-run ... --- qemu --show-boot ...
[19:04] <elopio> that should show more info. Not sure useful info, but more.
[19:07] <dobey> doesn't work here
[19:07] <dobey> adt-virt-qemu: error: unrecognized arguments: --show-boot
[19:08] <dobey> and -d there doesn't show naything
[19:10] <dobey> and this was working fine 6 months ago when i last ran this stuff :(
[19:12] <elopio> um, I am on vivid but have adt-run from wily. Maybe this is new.
[19:13] <elopio> but well, you shouldn't be surprised it stops working after 6 months without running it :)
[19:19] <dobey> why? i haven't changed distro versions. i haven't modified the image i'm testing on. the click package hasn't changed (though i'm trying to add new tests for making a bug fix now)
[19:19] <dobey> it shouldn't just stop working
[19:20] <dobey> the only thing this tells me is that i should just scrap all autopilot tests everywhere, because nobody actually uses these tools, so they're totally unreliable
[19:21] <dobey> and unreliable tests (and the tools needed to run them), are a waste of time
[19:26] <elopio> dobey: +1 to that. If nobody is running the tests daily, they are worthless.
[19:26] <elopio> however, I would suggest to fix them and start running them daily, of course.
[19:27] <dobey> elopio: there's no need to run the tests daily if changes aren't being made daily
[19:27] <dobey> i shouldn't have to run my own tests daily to ensure that the tools used to run those tests aren't breaking
[19:27] <elopio> dobey: you should run the tests against the development image, which changes daily.
[19:28] <dobey> nope
[19:29] <elopio> well, that's probably another problem. If the error is in qemu + image, nobody is running that combination either.
[19:30] <dobey> well, it's also not like i'm running the latest packages in development ubuntu all the time either
[19:30] <dobey> i'm doing this on an LTS host
[19:30] <dobey> i think there have been some security updates for qemu, but i wouldn't expect that to break things
[19:31] <elopio> there's also the chance that it has never worked.
[19:31] <elopio> but well, there are so many projects involved in this that things are delicate and break in unexpected ways.
[19:32] <dobey> well i know it worked because i ran the tests
[19:32] <dobey> and i refused to land the autopkgtest stuff in the click until i had it working reliably
[19:35] <elopio> I get an error creating the chroot as explained in the README ^_^
[19:35] <elopio> many broken things.
[19:36] <elopio> none of them your fault, I bet.
[19:36] <elopio> but if you don't run your tests daily, you won't find when somebody breaks your stuff, and you won't be able to make sure that they don't break it again.
[19:42] <dobey> i shouldn't have to manually run my tests daily
[19:45] <dobey> if the tests should be run manually, then it should be done via CI, where the image builds automatically run the autopkgtests configured for all the packages installed by default on that image
[19:47] <elopio> yes. By you I don't mean *just you*. Your team, somewhere, ideally automatically. But every day, that's the important part.
[19:57] <dobey> i have to disagree


[00:25] <sebner> bdrung: right, stays at "None" (even though I have effects enabled)
[01:01] <GanonKiller> is combat arms still in development for linux?
[01:07] <GanonKiller> is combat arms still in development for linux?
[02:39] <aakshay> hi.. i am making the package using the packaging guide. the rules file is not complete as shown in tutorial..
[02:40] <aakshay> does anybody know how to adjust rules file in pakaging..
[02:44] <aakshay> does anybody know how to edit rules file in pakaging.. its not showing makefile in it
[02:45] <RAOF> What do you mean?
[02:45] <RAOF> The debian/rules file is a makefile, with various standard targets that the build process calls to make things happen.
[02:46] <aakshay> raof: the rules file is not showin any rules in it
[02:46] <aakshay> raof: its been restricted by developer
[02:47] <aakshay> raof: its showin  < #!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make.  # Uncomment this to turn on verbose mode.
[02:48] <RAOF> aakshay: You should pastebin the rules file rather than paste it into IRC
[02:48] <RAOF> (The pastebinit tool is useful here)
[02:48] <aakshay> i m sorry.. i dont know how. it's my first time here...
[02:49] <aakshay> raof: can u plz tel where is the pastebin option?
[02:50] <RAOF> You can install the “pastebinit” package.  That gets you the pastebinit tool, which you can use like so: “pastebinit debian/rules”, and it'll copy the debian/rules file to a pastebin and then return the URL.
[02:50] <RAOF> You then want to paste the URL in here.
[02:51] <aakshay> thanx...let me do this... plz wait.
[02:51] <hallyn> if a bug affects debian as upstream, can i just hit 'also affects' in LP and it'll do the right thing wrt debian bugs, or do i need to separately file a debian bug through email?
[02:52] <RAOF> You need to separately file a debian bug through email; Launchpad doesn't (yet!) _actually_ forward the bugs upstream.  That's a way to link existing upstream bugs into the Launchpad bug.
[02:53] <hallyn> RAOF: thanks!
[02:56] <aakshay> roaf: URL is "http://pastebin.com/SsusCmzz"
[02:57] <aakshay> roaf: plz suggest something
[02:57] <RAOF> Right.  As I suspected.
[02:57] <RAOF> So, that *does* have all the targets of interest.
[02:57] <aakshay> sorry??
[02:57] <RAOF> The “%:” target is a catch-all target.
[02:57] <RAOF> It matches everything.
[02:57] <aakshay> okiez... it has this
[02:58] <aakshay> roaf: so wat i can do ?
[02:58] <RAOF> That's a fairly typical debhelper 7 rules file.
[02:58] <RAOF> aakshay: Well, what do you want to achieve?
[02:58] <aakshay> roaf: i am learning packaging
[02:59] <aakshay> so i came across this file to edit this
[02:59] <aakshay> roaf: but its not showing the complete rule file.. so i get stucked at this point
[03:00] <RAOF> That *is* the complete rules file.
[03:00] <aakshay> roaf: yes..
[03:01] <aakshay> roaf: please suggest something
[03:01] <RAOF> I'm not sure what you're trying to do.
[03:02] <aakshay> roaf: i m doin packaging using deb-helper..... for this we need to edit the control, changelog, rules etc files
[03:02] <RAOF> That rules file will work for a simple package with no unusual requirements.  Whether you need to modify it, and how you need to modify it, depends on what the software you're trying to package needs.
[03:04] <aakshay> roaf: i am using deb-helper and packaging the simple hello-2.1.1 soy=urce....m doing this from ubuntu packaging guide..
[03:05] <aakshay> roaf: *source
[03:06] <aakshay> roaf: thanx for help...;-)
[03:07] <RAOF> I'm still not sure what your question is :/
[03:10] <aakshay> roaf: my question is how can i view my rules file completely.... there is no rules defined in it....;)
[03:11] <RAOF> You *are* viewing your rules file completely.  That file defines a catch-all rule - “%:”.
[03:11] <aakshay> roaf: these rules are inbuilt in it.... which are not there in this file...
[03:11] <aakshay> okiez...
[03:12] <RAOF> So when debian/rules is called with “debian/rules build”, Make looks for the ‘build’ target, finds that ‘%:’ matches “build”, and executes the commands there (specifically, it runs “dh build”, because $@ gets substituted to the target name).
[03:14] <aakshay> roaf: okiez.. let me try it other way...
[03:14] <aakshay> roaf: thanx again for your help..;)
[03:15] <aakshay> roaf: bye...
[03:16] <RAOF> Good luck!
[03:20] <wgrant> lamont: The extras.ubuntu.com resigning stuff doesn't seem to be working. It's now signed with the original PPA key, which isn't in the default keyring.
[04:38] <RAOF> @pilot out
[04:44] <TheMuso> lol udevbot
[05:17] <RAOF> Ok!  Who'd like to burn a few CPU cycles sponsoring a new mesa & Radeon DDX?
[05:38] <RAOF> For those playing at home, http://cooperteam.net/Packages/mesa_7.9+repack-1ubuntu1.dsc and http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2-1ubuntu2.dsc are awaiting someone's pleasure.
[05:40] <StevenK> RAOF: You mean you aren't a coredev yet?
[05:44]  * RAOF takes this as more evidence it's time to get his application wiki page in order.
[05:45] <StevenK> RAOF: When you're done, point me at it and I'll stamp it
[05:46] <RAOF> Thanks :).
[05:46] <RAOF> I'm off for some exercise now; I'll be back online later.
[05:49] <StevenK> RAOF: http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2.orig.tar.gz is 404
[05:52] <RAOF> StevenK: Now it's there.
[05:52] <StevenK> RAOF: Yah, I just grabbed it, thanks
[05:52] <StevenK> RAOF: Slow wet string?
[05:52] <RAOF> No; forgetting to -sa
[05:53] <StevenK> Ha
[05:58] <RAOF> Note that there's a semi-dependency on the new mesa in the new xserver-xorg-video-ati
[05:59] <StevenK> RAOF: So mesa should be uploaded and built first?
[06:00] <RAOF> A new option in the new ati won't work until the new mesa is installed.
[06:01] <RAOF> Peoples systems won't break unless they add an xorg.conf option before installing the new mesa; I don't think the ordering is particularly important.
[06:02] <RAOF> Specifically, the ForceGallium option won't work until you've installed the new mesa, which builds the gallium driver.  It's only interesting if you want to test that.
[06:02] <RAOF> Now, really going off to exercise :)
[06:48] <kees> cjwatson: cpu-checker can be demoted to universe (I removed it from update-manager-common)
[06:58] <ebroder> Does...anybody know why apt-get update in my natty schroot would be giving "Undetermined Error" when trying to download the natty-updates Packages and Sources files from my approx server?
[07:01] <pitti> Good morning
[07:32] <dholbach> good morning!
[07:51] <ebroder> In the interests of whittling down the sponsoring queue, anybody want to mark https://code.launchpad.net/~hrw/ubuntu/natty/byobu/fix-cpu-freq-on-smp-arm/+merge/41427 as merged as of r89?
[07:51] <dholbach> ebroder, done
[07:52] <ebroder> Thanks
[07:52] <dholbach> de nada
[07:53] <ebroder> Looks like https://code.launchpad.net/~smoser/ubuntu/natty/euca2ools/euca2ools-1.3.1/+merge/41105 was merged as of r25
[07:54] <didrocks> good morning
[07:55] <dholbach> ebroder, done
[08:10] <dholbach> RAOF, I had a chat with amaranth about bug 395692 yesterday - he said that it's unmaintained upstream
[08:11] <dholbach> it's probably safe to just upload it
[08:17] <ebroder> dholbach: https://code.launchpad.net/~smoser/ubuntu/lucid/mountall/bug649591/+merge/37105, merged as of r337 :)
[08:18] <dholbach> server team ^ mark your branches as merged!
[08:18] <ebroder> dholbach: I'll stop and just harrass SpamapS next time I see him :)
[08:19] <ebroder> And smoser, I guess
[08:34] <RAOF> dholbach: Yeah.  I can't upload it, though, so I again call for sponsorship :)
[08:34] <dholbach> ok, I'll have a look into it in a bit
[08:52] <RAOF> StevenK: Are you able to upload mesa or -ati, or should I cast around for other sponsors?
[08:53] <pitti> RAOF: toss me the URL to a source.changes, I'm happy to upload stuff for you
[08:54] <StevenK> RAOF: I got distracted
[08:54] <StevenK> RAOF: Sorry
[08:54] <dpm> good morning cjwatson, great work with the interview on planet ubuntu, it was a very interesting read!
[08:54] <RAOF> StevenK: No problem.  I'll punt it to pitti, then, since it's late for you.
[09:14] <pitti> cjwatson: eww, "ps aux|grep cdimage" on antimony looks like there's a lot of stuck build live processes -- do you think we should kill them wholesale?
[09:23] <geser> somebody else having problems with booting his natty system? grub greeted me today with "grub rescue>" instead the usual menu :(
[09:24] <pitti> I just dist-upgraded and rebooted, worked fine here
[09:24] <pitti> geser: did some package (kernel/grub) fail to configure or so?
[09:24] <ebroder> geser: You probably didn't install the new grub, and the configuration doesn't seem to work with older grub
[09:24] <geser> not that I noticed on the update yesterday
[09:26] <geser> ebroder: I remember seeing the usual debconf question on which harddisk to install grub. What need I to do to fix it?
[09:26] <ebroder> geser: Check the logs from yesterday around, uh...22:46 UTC. Probably the same thing bdrung ran into
[09:27] <ebroder> geser: If you can manage to boot once, "grub-install /dev/sda" should fix it for now, and "echo SET grub-pc/install_devices /dev/sda | sudo debconf-communicate" should fix it forever (substituting your harddrive of choice for /dev/sda)
[09:27] <geser> ebroder: -rw-r--r-- 1 root root<PHONE_NUMBER>-11-24 18:22 /boot/grub/lua.mod (if you mean that)
[09:27] <ebroder> geser: Oh, never mind then
[09:28] <ebroder> geser: Well, following cjwatson's script from earlier, does "insmod normal" then "normal" get you anything interesting?
[09:30] <geser> ebroder: here is the output from debconf-show for grub-pc: http://paste.ubuntu.com/536214/
[09:30] <ebroder> geser: Yeah, this isn't bdrung's problem
[09:31] <geser> if it's matter I use RAID and LVM (/boot is on RAID1, / on LVM on RAID1)
[09:33] <ebroder> geser: Unfortunately it's 3:30AM my time, and I meant to go to sleep 2 hours ago. Hopefully cjwatson will be around soon and can undoubtedly be more helpful than me in any case
[09:34] <geser> I've to leave in a few minutes too (first for work then university) and should be back around 16 UTC
[09:43] <RAOF> pitti: When you're free, http://cooperteam.net/Packages/mesa_7.9+repack-1ubuntu1_source.changes and http://cooperteam.net/Packages/xserver-xorg-video-ati_6.13.2-1ubuntu2_source.changes
[09:46] <pitti> RAOF: debdiff looks fine to me; thanks, uploaded
[09:48] <RAOF> pitti: Thanks muchly.  That should get us a long way towards fitting on a CD.
[09:48] <pitti> oh, just uplaoded ati; /me looks at mesa
[09:49] <RAOF> Heh.  -ati's not going to slim the CDs down much :)
[09:50] <pitti> that's what made me wonder :)
[09:51] <pitti> oops
[09:51] <bilalakhtar> It appears there is a large list of NBS packages with no reverse deps. Why isn't someone cleaning them up?
[09:51] <pitti> RAOF: can you please rebuild the source.changes with -sa?
[09:51] <pitti> RAOF: my upload will be rejected, as the orig isn't there
[09:52] <pitti> bilalakhtar: it's mostly the old kernel ABI; cleaning up now
[09:52] <bilalakhtar> thanks pitti
[09:53] <RAOF> pitti: Ah, yeah, sorry.
[09:53] <pitti> RAOF: (if you rebuild, you'll have to reupload .dsc and diff.gz as well)
[09:55] <StevenK> bilalakhtar: It's a manual process
[09:56] <bilalakhtar> StevenK: of course it is :)
[09:56] <StevenK> From my looking, it's just a kernel
[09:56] <StevenK> You should see the list when it has 3 or 4 kernel versions in it
[09:57] <pitti> should look much better in the next runm
[09:57] <RAOF> pitti: There you go, should be good.
[09:58] <pitti> RAOF: yep, thanks; uploading
[09:58] <StevenK> pitti: You've already killed -5?
[09:59] <pitti> StevenK: yep, since d-i was rebuilt against -6
[09:59] <StevenK> pitti: Okay, then I won't try :-)
[10:00] <pitti> and the old .35-22 kernels, too, plus three "no rdepends" packages
[10:00] <pitti> warp10: warp11? physically impossible!
[10:00] <pitti> warp10: hey Andrea, how are you?
[10:00] <warp10> pitti: That's transwarp!
[10:01] <warp10> pitti: pretty fine, thanks, and you? :)
[10:01] <StevenK> Actually, I didn't think transwrap had numbers, they are just spacetime corridors?
[10:02] <pitti> warp10: I'm great, thanks!
[10:02] <bilalakhtar> pitti: Are you still in the OEM team or you're back?
[10:02] <warp10> StevenK: yeah, think so. Sort of conduits through transwarp space
[10:03] <warp10> StevenK: at least for Borg transwarp drive, IIRC
[10:03] <pitti> bilalakhtar: I'm back since last UDS
[10:03] <bilalakhtar> pitti: oh cool!
[10:09] <mdz> pitti, hi
[10:09] <pitti> hey mdz
[10:09] <mdz> pitti, wondering if the retracer is down; I filed a crash report yesterday which is untraced as yet (bug 680968)
[10:10] <pitti> mdz: seems the amd64 one is
[10:10] <seb128> pitti, do we have natty retracers already?
[10:10] <pitti> seb128: no, we don't
[10:10] <mdz> seb128, but that was a maverick crash
[10:10] <mdz> which the U1 team wants to look at
[10:10] <seb128> mdz, sorry I hijacked your question
[10:10] <pitti> restarted the amd64 one
[10:11] <mdz> pitti, thanks
[10:11] <pitti> mdz: thanks for pointing out; I guess LP rollout
[10:11] <seb128> mdz, I was just thinking about natty yesterday because of unity testing
[10:11] <seb128> mdz, I your question made me think about it again ;-)
[11:29] <cjwatson> kees: cpu-checker> the problem is that qemu-common recommends it
[11:30] <cjwatson> dpm: thanks :)
[11:30] <cjwatson> pitti: need to consult with lamont I think, as killing the trigger scripts on antimony won't kill the actual build processes on the livefs buildds
[11:30] <cjwatson> lamont: ^-
[11:31] <pitti> ah, right
[11:31] <pitti> lamont: it seems that there are a lot of stuck livefs build jobs on the buildds right now? at least antimony has a plethora of very old calls there (ssh sessions, right?)
[11:45] <soren> Argh.
[11:45] <soren> Just... argh.
[11:48] <bilalakhtar> soren: why?
[11:49] <mdz> pitti, thanks for getting the amd64 retracer back up. I can now see that my bug is one of many apparent duplicates with equivalent stack traces
[11:49] <pitti> :)
[11:49] <mdz> pitti, I wonder why the retracer did not match them as duplicates in fact
[11:49] <seb128> mdz, is there any missing symbols in the stacktrace?
[11:49] <seb128> like ?? lines
[11:50] <mdz> seb128, hmm, yes
[11:50] <seb128> that's why
[11:50] <mdz> there is one missing gobject symbol
[11:50] <seb128> the autodup works only with exact matches
[11:50] <seb128> exact and complete functions
[11:50] <pitti> mdz: there's some difference in the 4th and 5th line of stack trace top
[11:51] <mdz> pitti, a few, though there are many which have identical stacktracetop
[11:52] <mdz> seb128, I see, thanks
[11:52] <mdz> I wonder why it isn't resolving that symbol
[11:52] <soren> pitti: Is pkgbinarymangler's test suite supposed to work as a regular user (and on systems that already have it installed)?
[11:52] <pitti> soren: yes
[11:52] <pitti> it's supposed to take the local binaries
[11:52] <pitti> and it's all done in a temp directory
[11:52] <pitti> soren: it runs on the buildds during package build, after all
[11:52] <soren> pitti: If I run "test/run -v", I get a whole stack of these:     os.symlink('/usr/bin/dpkg-deb.pkgbinarymangler', os.path.join(self.srcdir, 'dpkg-deb.pkgbinarymangler'))
[11:52] <soren> OSError: [Errno 17] File exists
[11:53] <soren> pitti: Yes. As root.
[11:53] <pitti> soren: that's from a failed run, you have to remove this file manually
[11:53] <pitti> soren: I run it as user here
[11:53] <soren> pitti: Sorry, which one is "this file"? :)
[11:53] <pitti> dpkg-deb.pkgbinarymangler
[11:54] <soren> Oh, that one!
[11:54] <soren> Yeah, there it goes. Lovely. Thanks.
[11:54] <pitti> "bzr clean-tree --ignored --unknown" for the win :)
[11:54]  * pitti has that aliased as "bzcln"
[11:54] <soren> pitti: Now that I have you attention anyway. I'm stunned that noone has noticed that the dpkg-deb wrapper fails if the path has a space in it.
[11:54] <mdz> the libglib and libgobject symbol info seems to be missing
[11:55] <pitti> soren: it happens seldomly enough
[11:55] <seb128> mdz, could be that the ddeb retrievers bugged and that there is no dbgsym for glib on that arch for that version
[11:55] <ari-tczew> archive admins: why squid3 is on blacklist? there is a new debian revision merge. is it possible to do?
[11:56] <soren> pitti: Err.. Except when you click on a deb on a web site and it attempts to get installed through software center.
[11:56] <pitti> soren: I try to quote my variables, but well, it's shell..
[11:56] <soren> pitti: I have a patch, just need a test case.
[11:56] <pitti> soren: what's that to do with the mangler?
[11:56] <soren> pitti: If someone has pkgbinarymangler installed, and their locale's "Downloads" has a space in it (in Danish it's "Hentede Filer
[11:56] <soren> "), you can't install deb's from firefox.
[11:57]  * cjwatson is currently running http://paste.ubuntu.com/536260/ - approach may be of interest to others with large queues of apport-generated bugs
[11:57] <seb128> mdz, doesn't seems to be the case, http://ddebs.ubuntu.com/pool/main/g/glib2.0/
[11:57] <seb128> not sure why then...
[11:57] <cjwatson> (sort of like a special-purpose version of bughelper optimised for very quickly scanning and duplicating lots of bugs onto a known base)
[11:57] <pitti> soren: I'm still puzzled, but perhaps it'll clear up in your MP
[11:58] <soren> pitti: I'm not sure what is unclear.
[11:58] <soren> ?
[11:58] <soren> pitti: ...and if I don't know, I can't clarify it in my mp :)
[11:58] <cjwatson> ari-tczew: squid3 # overrides squid-cgi; needs manual resolution
[11:58] <pitti> soren: where does the mangler come into play when you install .debs from firefox?
[11:58] <ari-tczew> cjwatson: I see this one. so, merge-able
[11:58] <ari-tczew> ?
[11:58] <cjwatson> may not be true any more
[11:58] <soren> pitti: It wraps dpkg-deb
[11:59] <soren> pitti: dpkg -i -> dpkg-deb -x -> fail
[11:59]  * cjwatson checks the bzr history
[11:59] <pitti> aah
[11:59] <ari-tczew> cjwatson: is it possible to check who did this change?
[11:59] <pitti> soren: right, now I understand; sorry :)
[11:59] <cjwatson> log message was "initial sync blacklisting for maverick"
[11:59] <cjwatson> it was probably me
[11:59] <cjwatson> I can't check for sure due to the way the archive admin shell access setup works
[11:59] <cjwatson> but I don't think it matters
[12:00] <ari-tczew> cjwatson: I dunno why this one didn't handle by MoM?
[12:00] <cjwatson> ari-tczew: because it ignores everything on the sync-blacklist
[12:00] <cjwatson> ari-tczew: I've unblacklisted it
[12:00] <ari-tczew> cjwatson: thanks!
[12:01] <ari-tczew> cjwatson: another issue with MoM: do you think that adding blank line at the end of debian/changelog is an issue?
[12:02] <cjwatson> yes, though a minor one
[12:02] <ari-tczew> cjwatson: ok, I'll report a bug
[12:22] <seb128> mdz, pitti: ok, I figured why the glib symbols are missing
[12:23] <mdz> seb128, oh! what is it?
[12:23] <seb128> mdz, pitti: the retracers doesn't have a maverick-updates ddeb source
[12:23] <pitti> oh, crud
[12:23] <seb128> I'm fixing it
[12:23] <pitti> seb128: merci
[12:23] <seb128> they still have lucid-proposed and lucid-updates
[12:23] <seb128> pitti, yw
[12:23] <pitti> seb128: that was because we often copy SRUs from lucid-proposed to maverick (same for natty)
[12:24] <pitti> but that doesn't reflect on the ddebs archive
[12:24] <pitti> seb128: so please leave those in
[12:24] <pitti> (proper soyuz support for ddebs FTW..)
[12:24] <seb128> ok
[12:24] <seb128> I will just add the maverick ones
[12:24] <mdz> seb128, nice work
[12:24] <seb128> thanks ;-)
[13:12] <ari-tczew> pitti: could you accept packages in karmic-proposed? ;-)
[13:13] <bilalakhtar> ari-tczew: <pitti> Pinging an ~ubuntu-sru member to accept packages won't help, sorry
[13:13] <bilalakhtar> that's what he said to me a few months ago
[13:14] <ari-tczew> bilalakhtar: odd.
[13:14] <bilalakhtar> ari-tczew: try the poke, since karmic-proposed is a somewhat staler section of SRUing ATM
[13:16] <ari-tczew> bilalakhtar: SRU work should be welcome. Answer which you showed me is pretty ignorant.
[13:17] <bilalakhtar> ari-tczew: my answer was for an SRU into lucid-{proposed,updates} at a time when maverick was devel release
[13:17] <soren> pitti: Can you review lp:~soren/pkgbinarymangler/no-mangle-args please?
[13:17] <bilalakhtar> your case is different
[13:17] <bilalakhtar> soren, ari-tczew: pitti seems /away for lunch
[13:18] <soren> bilalakhtar: I can wait :)
[13:20] <ari-tczew> bilalakhtar: I say that pitti's answer seems to ignorant, not yours.
[13:20] <bilalakhtar> ari-tczew: in that line, s/my/pitti's/
[13:21] <mr_pouit> and why would it be "ignorant"?
[13:23] <ari-tczew> this answer is like 'I don't care, not my problem, still wait'
[13:24] <mr_pouit> or maybe "~ubuntu-sru members aren't archive admins, only archive admins can accept packages, so you have to wait for the next archive admin day"?
[13:25] <mr_pouit> but it's better to jump to conclusion as you did, and treat people as ignorant :]
[13:27] <ari-tczew> mr_pouit: I'm pinging pitti as archive admin, not as sru team member.
[13:28] <ari-tczew> and I'm not here to guessing about other people sentences
[13:28] <ari-tczew> answer is answer
[13:28] <seb128> the point is that people do work on those tasks when they have time
[13:29] <seb128> doing IRC ping is usually of no use, it just create stress and discussions
[13:29] <seb128> if you wait a bit SRU will be reviewed in the regular way
[14:00] <ari-tczew> cjwatson: could you also take a look on package 'fai' on blacklist?
[14:00] <ari-tczew> it seems to be outdated
[14:00] <ari-tczew> \sh: has uploaded changes this year
[14:00] <cr3> hi folks, anyone happen to know if there's a way to enable a wireless card, bcm4322 in this case, where rfkill unblock still doesn't seem to unblock the interface?
[14:02] <\sh> ari-tczew: stop spreading fud pls...fai is already updated on maverick
[14:02] <\sh> ari-tczew: and it's a native ubuntu package, because we really can't sync from debian at this stage
[14:03] <ari-tczew> \what do you want from me? version looks like merged with debian. if version is -0ubuntu1 then it suggests to be ubuntu packaging
[14:04] <ari-tczew> \sh:  ^
[14:05] <\sh> ari-tczew: https://launchpad.net/ubuntu/+source/fai/3.4.3ubuntu1 <- this is an ubuntu native package
[14:05] <azeem> how would a debian-native-with-ubuntu-changes version look like?
[14:06] <\sh> azeem: the same like an ubuntu native
[14:06] <azeem> ok
[14:06] <ari-tczew> lol
[14:06] <azeem> so in essence, it wasn't really possible for ari-tczew to tell
[14:07] <\sh> azeem: you can see it on ubuntu1 ?
[14:07] <\sh> if it's a package with -0ubuntu1 (which is actually not a native package) but a package with originates in ubuntu
[14:07] <azeem> whatever
[14:08] <azeem> I still think it wasn't obvious that 3.4.3ubuntu1 is a ubuntu native package and doesn't need a merge to 3.4.4
[14:08] <\sh> if it's a package with something behind the version+<somthing like an ubuntu string> it's normally a native with ubuntu changes
[14:09] <mdz> dholbach, where do the minutes from CC meetings get posted?
[14:10] <cjwatson> ari-tczew,\sh: it was sync-blacklisted because it had been removed, so it makes sense to unblacklist it now (the Ubuntu version number will still stop it being autosynced, but now it will at least show up on MoM)
[14:10] <cjwatson> ari-tczew: ideally, just file bug reports about these things and subscribe ubuntu-archive, so that the archive admin of the day can take care of them
[14:11] <ari-tczew> cjwatson: ATM \sh blamed me about unblacklist
[14:11] <cjwatson> well, the reason for the blacklist entry no longer applies so I've removed it
[14:11] <ari-tczew> aha
[14:11] <\sh> cjwatson: oh well...
[14:12] <cjwatson> \sh: I think you may misunderstand what the sync-blacklist does
[14:12] <ari-tczew> maybe archive admins should review all list to get update information
[14:12] <pitti> ari-tczew: I can, yes
[14:12] <cjwatson> \sh: packages that simply have Ubuntu changes don't belong there - there are other, better, ways to stop them being synced
[14:13] <\sh> cjwatson: no..there was a reason...I think the sync blacklist entry was already there before it was even removed...I can't remember anymore..but in the past there was this ubuntu fai team who took care about FAI
[14:13] <cjwatson> the sync-blacklist is for (a) packages that break the autosync process for one reason or another, usually binary package name clashes with another source package but occasionally something else (b) packages that have been deliberately removed from Ubuntu but are still in Debian (c) packages that are divergent in Ubuntu but don't use the *ubuntu* versioning scheme
[14:14] <cjwatson> \sh: the blacklist entry said you are mistaken
[14:14] <cjwatson> fai # stevenk, blacklisting due to removal, see bug 419099
[14:14] <cjwatson> \sh: when it was simply modified in Ubuntu, it did not require a sync-blacklist entry
[14:14] <cjwatson> \sh: this is a non-issue, really
[14:15] <pitti> soren: looking
[14:16] <\sh> cjwatson: ok..as said, I thought there was already such an entry before the removal...what could we do to only have a special group of people taking care of this package?
[14:17] <cjwatson> \sh: you already have that
[14:17] <cjwatson> \sh: you don't need a sync-blacklist entry for that.  it's a great big hammer for special purposes that have nothing to do with what you're asking.
[14:19] <cjwatson> \sh: of course, that special group of people must include MOTU; Ubuntu development is cooperative and they have upload access.  But I'm sure that they generally won't walk over your changes if the package is generally being well-maintained.
[14:19] <cjwatson> if somebody's clearly actively taking care of a package then that's generally sufficient for MOTU to leave them to it
[14:21] <\sh> cjwatson: so best practice as always...
[14:24] <pitti> soren: nice one, thanks! merged, uploading now
[14:24] <soren> pitti: np
[14:24] <pitti> soren: hm, seems that lool beat me to it
[14:25] <soren> pitti: Ah. Yeah, I wanted to make you the reviewer, but launchpad beat me to it and sent it to everyone.
[14:25] <pitti> lool: are you going to upload mangler, or want me to?
[14:28] <pitti> lofidellity: uploading now
[14:29] <pitti> sorry lofidellity
[14:29] <pitti> lool: mangler uploaded, FYI
[14:31] <lool> pitti: I was takingit, yes
[14:31] <lool> pitti: I assigned it to me and pushed the changes
[14:31] <freeflying> pitti, how can I make changes to language-support-input-zh-hans?
[14:31] <lool> pitti: I did additional tweals
[14:31] <lool> tweaks
[14:32] <pitti> lool: merci
[14:32] <pitti> freeflying: in lp:langpack-o-matic, support-depends/*
[14:32] <pitti> freeflying: you can tell me what needs to be changed, or do a branch
[14:33] <pitti> freeflying: then I'll need to rebuild the package (that happens mostly automatically)
[14:33] <freeflying> pitti, I will make a branch, and send you for review
[14:33] <pitti> freeflying: thank you!
[14:33] <freeflying> pitti, or which way you prefer?
[14:34] <pitti> freeflying: branch sounds great
[14:35] <freeflying> pitti, ok
[14:37] <pitti> tseliot: FYI, I'm going to convert bcmwl to the new dh_modaliases in lp:ubuntu/bcmwl, so that I have a real-world test case for jockey development
[14:38] <lamont> pitti / cjwatson: still wondering about those livecdfsbuilds?
[14:38] <tseliot> pitti: great! I look forward to seeing the result of your work :)
[14:38] <pitti> lamont: cdimage@antimony:~$ ps ux|grep buildlive|wc -l
[14:38] <pitti> 56
[14:38] <pitti> lamont: so, yes
[14:39] <pitti> tseliot: dh_modaliases exists now, test case, too; now I need to add the jockey support for it
[14:39] <pitti> tseliot: (exists in my local branch, not uploaded yet)
[14:39] <freeflying> pitti, I plan to make language-support-input-zh-hans depends on ibus | fcitx, does the scripts support it?
[14:39] <pitti> freeflying: yes, the dependencies are just copied verbatim
[14:40] <tseliot> pitti: good. I'll do my part in nvidia-*, fglrx and in nvidia-common (the python library) when dh_modaliases is uploaded
[14:40] <freeflying> pitti, and there is no natty available under support-depends, so I'd make changes in maverick? thanks
[14:41] <pitti> freeflying: actually no, we need to copy maverick/ to natty/ first and then change stuff there
[14:41] <pitti> freeflying: it's the first support-depends change in natty
[14:41] <freeflying> pitti, I see
[14:42] <cjwatson> pitti: is that something that somebody needs a reminder of as part of NewReleaseCycleProcess?
[14:43] <lamont> pitti: you just want me to kill the amd64/i386 livefs builds with fire?
[14:43] <freeflying> pitti, so are you going to copy it first, and then I make my branch? or vice versa?
[14:43] <pitti> cjwatson: we could add it there, but since these never get uploaded automatically, it could just happen when first needed
[14:43] <cjwatson> hm, ok
[14:43] <pitti> freeflying: I can do that now and push if you want to
[14:44] <pitti> freeflying: (before you branch)
[14:44] <pitti> cp -r support-depends/{maverick,natty}; bzr add support-depends/natty; bzr commit
[14:44] <pitti> something like that
[14:45] <freeflying> pitti, thanks, then I will branch it after your push :)
[14:45] <Rovanion> When running autogen.sh to build Docky from source I get the error that I'm missing the package: 'gnome-keyring-sharp-1.0'. There seems to be no such package in the Ubuntu repositories or Docky PPA. What can I do?
[14:45] <pitti> freeflying: done
[14:46] <pitti> lamont: I guess we can just eradicate them all and start over at that point; not much value at trying to rescue the two "good" ones (if there are any)
[14:46] <Laney> Rovanion: This isn't the channel for such questions, but that is an error for pkg-config. The file you're looking for is called gnome-keyring-sharp-1.0.pc. It's in libgnome-keyring1.0-cil-dev.
[14:46] <Laney> (in general, try apt-get build-dep packagename)
[14:46] <lamont> amd64 had nothing queued, i386 had a plethora
[14:47] <Rovanion> Laney, apt-get build dep has been failing because, according to #ubuntu, some amd64 repository is down
[14:48] <lamont> i386 is clean and waiting for you
[14:48] <pitti> lamont: cheers; buildlive processes are down to 8 now (from 56)
[14:49] <ml> hello. im looking for an ubuntu dev to help resolve a package issue regarding main inclusion
[14:49] <pitti> lamont: for xubuntu, kubuntu, mythbuntu, and ubuntu DVD
[14:49] <lamont> cool.   back to my day off then
[14:49] <pitti> lamont: oh, enjoy Thanksgiving!
[14:49] <Rovanion> Laney, I seem to have cleared my xchat log with a keybinding. What were you saying that I should do? And forgive me for using the wrong channel. I thought this was where I should turn to get help when developing in an Ubuntu environment
[14:49] <pitti> lamont: will the remaining 8 just time out by themselves?
[14:49] <lamont> which architecture are they?
[14:50] <pitti> hm, how do I tell?
[14:50] <lamont> hrm... /me goes and looks
[14:50] <pitti> ssh -t -o StrictHostKeyChecking no -o BatchMode yes<EMAIL_ADDRESS>/home/buildd/bin/BuildLiveCD -s ps3 -d natty xubuntu
[14:50] <cjwatson> look for the ssh processes and look up the hostnames in cdimage/bin/buildlive
[14:50] <pitti> lamont: oh, royal -- is that ppc?
[14:50] <lamont> ppc
[14:50] <pitti> cjwatson: right, figured a second after I asked, sorry
[14:50] <cjwatson> powerpc+ps3 runs sequentially after powerpc
[14:50] <lamont> more to the point, what machines are they.
[14:50] <cjwatson> so that would be the natural result of killing a powerpc livefs build
[14:51] <pitti> lamont: I see exactly one ssh process to royal
[14:51] <lamont> I only killed the ones on cardamom
[14:51] <lamont> from 10:06 london time today
[14:51] <lamont> want it dead, or let it run?
[14:52] <Riddell> ml: what's up?
[14:52] <pitti> lamont: I guess kill them all for now
[14:52] <pitti> lamont: I have a hunch that they took ages because of the apt compressed indexes thing
[14:52] <pitti> that hit UEC builds as well
[14:52] <pitti> I uploaded a new apt this morning which reverts that
[14:53] <pitti> so they will hopefully work now
[14:53] <ml> Riddell, i need to get help to resolve lp bug #311029 if possible. to resolve it we need to move libssh2-dev to main. current situation is that curl is configured without ssh support because libssh2-dev is in universe
[14:53] <lamont> I see no ssh-invoking-BuildLiveCD processes on antimony
[14:53] <lamont> s/no/no more/
[14:54] <ml> Riddell, decision to disable ssh in curl was made in lp bug #175891
[14:54] <pitti> lamont: I killed the cron.daily-live processes around it now, so that they stop running into each other
[14:55] <apw> is anyone running near alpha-1 natty with the traditional UI ?
[14:55] <pitti> lamont: as I said, there was just one:
[14:55] <apw> i don't seem to have any window decorations
[14:55] <lamont> cool. victory and turkey are mine
[14:55] <pitti> cdimage  22326  0.0  0.0  46384  3392 ?        S    10:26   0:00 ssh -t -o StrictHostKeyChecking no -o BatchMode yes<EMAIL_ADDRESS>/home/buildd/bin/BuildLiveCD -s ps3 -d natty xubuntu
[14:55] <pitti> lamont: thanks a bunch!
[14:55]  * apw notes that in english 'thanks a bunch' is generally carries negative connotations
[14:56] <pitti> apw: thanks for pointing out
[14:56] <pitti> lamont: so, "thank you very much" :) (and enjoy the turkey)
[14:56] <apw> 'thanks a lot!' is more happy sounding
[14:56] <diwic> pitti, setting "APPORT_SYMPTOMS_DIR=. ubuntu-bug audio" does not seem to work, it still looks for it in /usr/share/apport/symptoms
[14:56] <lamont> apw: depends on the tone.
[14:56] <Riddell> ml: we generally don't want two libraries in main doing the same thing, and libssh is already in main, so a start would be to check if curl can be made to use libssh instead of libssh2 or if whatever uses libssh can be made to use libssh2
[14:57] <pitti> diwic: hmm:
[14:57] <pitti> symptom_script_dir = os.environ.get('APPORT_SYMPTOMS_DIR',
[14:57] <pitti>                                     '/usr/share/apport/symptoms')
[14:57] <diwic> pitti, what file is that in?
[14:57] <pitti> diwic: does it work with `pwd`? there might be a chdir issue here
[14:57] <lamont> apw: interesting, both 'thanks a lot' and 'thanks a bunch' (and 'thank you very much') can go either way easily
[14:57] <pitti> diwic: /usr/share/pyshared/apport/ui.py
[14:58] <apw> lamont, yeah though i tend to assume bunch is bad and lot is good when in a tonless environ such as here
[14:58] <ml> Riddell, okay hm. i read some about that and it seems to me that libssh2 is superior (support multithreading, active developed and so on) but i understand the reasoning. heres what i refer to http://www.libssh2.org/libssh2-vs-libssh.html
[14:58] <lamont> I'll remember that.:-p
[14:58] <apw> :)
[14:58] <diwic> pitti, aha, I'm running a too old version of apport, I guess
[14:59] <pitti> diwic: ah, sorry; it's just in natty
[14:59] <lamont> I mostly go with my knowledge of the speaker, and assume they're thanking me if I don't know them.  That has the bonus value of annoying the sarcastic unknown twits
[14:59] <Riddell> ml: but otherwise you want to follow https://wiki.kubuntu.org/MainInclusionProcess to get libssh2 into main
[15:00] <diwic> pitti, as a workaround, can I copy ui.py to ".", hack it, and have PYTHON_PATH set to ".", would it pick up the right ui.py then?
[15:00] <ml> Riddell, also cant find any evidence that curl would compile with libssh, only libssh2 is mentioned in the manual
[15:01] <pitti> diwic: yes, except that it's PYTHONPATH :)
[15:01] <pitti> diwic: or install python-apport from natty
[15:01] <Riddell> ml: so needs checking if kdebase-runtime and remmina can compile with libssh2
[15:02] <ml> Riddell, (i dont even use the kde kubuntu) ;-)
[15:03] <dholbach> mdz, we haven't had anything on our agenda for quite a while, but also only managed to meet very irregularly - whenever we did we put minutes into the team reports
[15:03] <mdz> dholbach, so they only go into the team reports, not also emailed to a list or something?
[15:03] <dholbach> mdz, which list do you think would make sense?
[15:03] <diwic> pitti, I noticed that more than 10 options does not work well with apport-cli, is that fixed in natty as well?
[15:04] <pitti> diwic: that's news to me
[15:04] <pitti> I don't think I ever specified more than 3
[15:04] <Riddell> ml: that's irrelevant, if you're doing packaging in ubuntu you work everywhere you need to
[15:04] <mdz> dholbach, I'm not sure. The TB usually sends them to ubuntu-devel-announce
[15:04] <dholbach> yes, because it's "technical news"
[15:05] <mdz> dholbach, what's the equivalent for non-technical news?
[15:05] <dholbach> I feel it'd drown in noise in ubuntu-users@ and other places
[15:05] <dholbach> ubuntu-news? :)
[15:05] <diwic> pitti, ok, anyway, it shows up as "10" and when you want to select that, pressing the "1" in "10" makes it take the 1 item instead
[15:05] <ml> Riddell, okay :) i checked that libssh2 dont have any dependencies outside main
[15:05] <dholbach> but I don't think that's a mailing list any more
[15:05] <dholbach> like a public one
[15:10] <pitti> tseliot: hmm - bcmwl has debian/patches/*, but the debian/rules never actually applied them
[15:10] <tseliot> pitti: right, because dkms does
[15:10] <pitti> tseliot: ah, right
[15:10] <pitti> tseliot: i. e. we need to ship them, not apply them inline?
[15:11] <tseliot> pitti: yep
[15:11] <pitti> thanks
[15:11] <tseliot> np
[15:11] <pitti> tseliot: so, no "3.0 (quilt)" for now :)
[15:11] <tseliot> pitti: no, not yet ;)
[15:13] <ml> Riddell, i created MIR request in lp bug #681423  does it look ok?
[15:17] <Riddell> ml: " it replaces libssh" have you checked if it can do that?
[15:18] <Riddell> ml: this will be a security concious package, have you checked its security history?
[15:18] <pitti> tseliot: actually, would it be that bad to apply the patches at source package build time already?
[15:19] <pitti> tseliot: it'd remove the requirement for "patch" at runtime
[15:19] <pitti> tseliot: but it might be a license problem?
[15:19] <tseliot> pitti: yes, unfortunately, since we have to apply different patches for different kernel versions
[15:19] <pitti> ok
[15:19] <ml> Riddell, hm your right. can i reword it into "it can be made to replace libssh, already in main" ?
[15:22] <Riddell> ml: well do you know that it can?
[15:23] <ml> Riddell, well yes. but it would require rewriting some parts of applications currently using libssh.. so its not a trivial undertaking. the libssh2 does not seem to offer a libssh wrapper api
[15:23] <geser> cjwatson: how can I debug the cause for my grub boot issue in natty? I get only an error about a not found UUID and a grub_rescue prompt (I try booting from a RAID)
[15:24] <Riddell> ml: right, so for the mean time it would need to duplicate what libssh does, that should go in the MIR
[15:25] <pitti> tseliot, superm1: FYI, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/bcmwl/natty/revision/21 are the packaging changes to use dh_modaliases, and http://paste.ubuntu.com/536335/ is the result
[15:26]  * tseliot has a look
[15:26] <pitti> tseliot, superm1: oh, adding a Conflicts:/Replaces: to the old modalias package now, to clean up on upgrade
[15:26] <cjwatson> geser: what happens when you 'insmod normal'?
[15:26] <cjwatson> geser: and were there any errors on upgrade?
[15:27] <tseliot> pitti: it sounds good to me
[15:27] <geser> cjwatson: I don't remember seeing any errors on upgrade
[15:28] <ml> Riddell, ok thanks ill rewrite that.. also looking for past security issues
[15:28] <pitti> tseliot: it just occurred to me that this has a nice side effect: we don't explicitly need to test for apt package sources in jockey any more, since the package headers just won't be available when the driver packages aren't
[15:31] <tseliot> pitti: do you mean to say that jockey currently checks the availability of universe and multiverse?
[15:31] <pitti> tseliot: right after a fresh installation you won't have any apt packge lists, you need to run apt-get update first
[15:31] <geser> cjwatson: "error: unknown filesystem" when I try "insmod normal"
[15:31] <pitti> tseliot: before jockey actually checked that, you would get the drivers displayed, but they wouldn't install, because the package wasn't available in apt yet
[15:32] <pitti> tseliot: now, as soon as you enable multiverse, or any other repo with extra drivers, they will just be picked up by jockey at the right time
[15:33] <tseliot> pitti: aah, I see what you mean now. It should happen the same in case of PPAs. This is definitely a welcome feature :)
[15:33] <apw> pitti, i assume you get informed of merge-requests for udev automaticially ?
[15:33] <cjwatson> geser: how about 'ls', and could you also give me the module names listed by 'lsmod'?
[15:33] <pitti> apw: I'm not sure; did you just send one?
[15:34]  * pitti syncs mail
[15:34] <apw> https://code.launchpad.net/~apw/udev/volume-key-updates/+merge/41870
[15:34] <pitti> apw: yep, got it
[15:34] <apw> pitti, cool, wondered how automated it really was
[15:34] <pitti> apw: note that I won't directly merge this, I'll apply the changes upstream and then get it from there
[15:35] <apw> pitti, ahh should i be doing something different to get these to your attention thats easier to handle?
[15:35] <pitti> apw: it's automatic and easy "enough" for me, but if you prefer, you can send format-patch files against upstream git
[15:36] <pitti> apw: (with those it'll be super-easy for me to push them upsream)
[15:36] <pitti> apw: git://git.kernel.org/pub/scm/linux/hotplug/udev.git
[15:37] <geser> cjwatson: ls => (hd0) (hd1) ; lsmod => Unknown command 'lsmod'
[15:37] <apw> pitti, will do
[15:37] <pitti> apw: (but don't worry too much about this one; I'll just get the diff from the MP)
[15:37] <ari-tczew> what do you think, makes sense rebuild libproxy in karmic? bug 456907
[15:38] <cjwatson> geser: blast, no lsmod.  I suspect the appropriate raid modules weren't built-in.  can you get in with a live CD?
[15:38] <apw> pitti, well if you are going to do so feel free to take a 'Signed-off-by: Andy Whitcroft<EMAIL_ADDRESS>for them
[15:38] <pitti> apw: I was going to set you as the author, and me as sign-off
[15:38] <pitti> credit where credit is due :)
[15:39] <geser> cjwatson: sure, luckily I have an USB stick with grub lying around from which I can boot
[15:39] <apw> for the kernel the author is also mean to sign them off, so if you need them
[15:39] <apw> sign them off as well, and everyone in the chain as it were
[15:40] <pitti> apw: ah; udev is small, we don't care much about that really
[15:41] <apw> pitti, whatever works :)
[15:41] <ebroder> apw: I'm having problems with window decorations in my natty VMs (and NVIDIA machines). It looks like compiz is erroring out (possibly segfaulting?) instead of falling back to metacity when you don't have OpenGL support
[15:41] <apw> ebroder, that might explain my mess
[15:42] <ebroder> apw: My panel still worked, so I was able to open a terminal and run metacity by hand
[15:42] <cjwatson> geser: once you've chrooted in and bind-mounted /dev /proc /sys, I need the output from 'sudo grub-install --debug <whatever your usual grub-install devices are, probably /dev/sda and /dev/sdb?>'
[15:43] <apw> ebroder, for me the appearance settings have been turned to 'None', so far turning them back has worked ...
[15:44] <ebroder> apw: Huh, if you can get compiz to run at all, sounds like you have a different issue
[15:44] <apw> ebroder, i think it just died
[15:46] <ml> Riddell, i updated description for #681423
[15:50] <Riddell> ml: groovy, now you just wait for a main inclusion person to get round to doing the review
[15:50] <Riddell> ml: you should probably comment on the original bug pointing at the MIR bug
[15:50] <ml> Riddell, thanks alot for your help! i did point out the MIR bug :)
[15:51] <ml> Riddell, somewhat offtopic, digging around i found somewhat discouraging traces from libssh developer regarding not wanting to merge the libs into a single effort: http://daniel.haxx.se/blog/2010/03/04/two-competitors-or-one-united/
[15:53] <Riddell> tsk
[15:53] <ml> riddell, and it seems libssh2 is from one of the curl devs, probably why they didnt try to support libssh
[15:56] <geser> cjwatson: http://bienia.de/tmp/grub_sda.log and http://bienia.de/tmp/grub_sdb.log
[16:00] <cjwatson> /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=abstraction --device /dev/md0
[16:00] <cjwatson> devabstraction_module=
[16:00] <cjwatson> hmm with a capital hmm
[16:01] <cjwatson> geser: I think  sudo grub-probe -vv --device-map=/boot/grub/device.map --target=abstraction --device /dev/md0  should be the next step
[16:04] <dmart> kees: hi, do you have a moment?
[16:04] <geser> cjwatson: http://bienia.de/tmp/grub-probe.log and http://bienia.de/tmp/device.map if you need the device.map too
[16:05] <cjwatson> geser: yes, indeed I was going to ask for that.  I think the problem is that you have your md devices listed in device.map
[16:06] <cjwatson> when you list a device in device.map, grub treats them as if they were BIOS-accessible
[16:06] <geser> so edit the device.map and leave only the harddisk in and rerun grub-install?
[16:06] <cjwatson> this policy was less clear in the past and maybe you added them to work around some other bug, or you might just have suffered from this changelog entry:
[16:06] <cjwatson>     - Don't include MD devices when generating device.map (if you're using
[16:06] <cjwatson>       RAID and upgraded through 1.98+20100702-1 or 1.98+20100705-1, you may
[16:06] <cjwatson>       need to fix this up manually).
[16:07] <cjwatson> (grub2 1.98+20100706-1)
[16:07] <cjwatson> there was a 1.98+20100705-1ubuntu1 version in maverick with this flaw, unfortunately
[16:07] <geser> I didn't add them manually
[16:07] <cjwatson> ok, you were probably unlucky enough to have upgraded through that version then
[16:08] <cjwatson> maybe I should try to clean it up automatically, I was just scared of breaking some working setup
[16:08] <cjwatson> it might have to be a debconf question :-/
[16:11] <geser> cjwatson: http://paste.ubuntu.com/536354/ after I deleted the entries for (hd2) and (hd3)
[16:11] <ari-tczew> doko: could you take  a look for this bug 681447 ?
[16:12] <cjwatson> hmm
[16:12] <cjwatson> geser: maybe I broke RAID scanning or something.  can you wait while I bring up a test environment?  might take a little while
[16:13] <geser> sure, no hurry
[16:13] <cjwatson> thanks
[16:13] <cjwatson> it's possible, there was a hairy patch merge that could have been relevant
[16:14] <geser> cjwatson: my setup is: md0 is a RAID1 for /boot and md1 is LVM-on-RAID1 for /, /home, etc.
[16:15] <geser> I know how I can boot my system from my usb-stick with grub, so this is only a big annoyance currently for me
[16:17] <cjwatson> I'll try to mimic that as closely as I can
[16:19] <seb128> mdz, do you still have the .crash for the bug you reported earlier? do you think you could submit it again to see if the retracer works for the glib symbols now?
[16:21] <mdz> seb128, I do, yes
[16:21] <mdz> seb128, now?
[16:21] <seb128> mdz, when you want
[16:21] <seb128> mdz, the retracer are running with the updated sources
[16:21] <mdz> seb128, uploading now, it is 60MB so will take a little while
[16:22] <seb128> ok, thanks
[16:22] <mdz> seb128, right, that's what I meant. thanks.
[16:22] <mdz> hmm, actually apport must be reporting the uncompressed size, it's only a 3.6MB file
[16:24] <mdz> seb128, https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/681460
[16:25] <seb128> mdz, thanks
[16:41] <cjwatson> http://status.qa.ubuntu.com/qapkgstatus/grub2 - quite pleased with that for a day's bug work
[16:42] <ogra_ac> yeah, you mopped up a lot of dirt today
[16:42] <doko> ari-tczew: why? just merged it
[16:42]  * ogra_ac is happy to finally have hix bugmail box getting quiet again :P
[16:42] <pitti> cjwatson: you triaged ~600 bugs?!? wow
[16:43] <pitti> cjwatson: ah, I guess part of that was your magic script you pointed out earlier?
[16:43] <cjwatson> pitti: sadly I think you read that wrong :-)
[16:43] <cjwatson> ah, the colours are misleading
[16:43] <pitti> cjwatson: triaged went up from ~30 to a little under 600
[16:43] <cjwatson> the top circle is actually where the New line will drop to when it next draws a line segment
[16:44] <ogra_ac> should be between 100 and 200 i'd guess by the bugmail i got
[16:44] <cjwatson> I don't know why the colours don't match
[16:51] <geser> can a core-dev please give-back libssh on amd64? it failed to upload due to a bug in LP. https://launchpad.net/ubuntu/+source/libssh/0.4.5-2/+build/2012262
[16:51] <seb128> geser, done
[16:52] <geser> thanks
[16:52] <seb128> yw
[16:52] <siretart> pitti: regarding the new emacs upload: with '23.1+1-4ubuntu7.1' being in lucid-proposed, would '23.1+1-4ubuntu7.1+maverick1' be an acceptable version number for maverick-proposed?
[16:53] <pitti> siretart: yes, but a simple 7.2 will do as well; or 7.10.10
[16:54] <siretart> ok. I'd prefer to go with +maverick1, because then we can still use 7.2 for the next lucid SRU.
[16:55] <ari-tczew> doko: I saw subscribed toolchain hackers, so I'd ask you for review or sponsorship
[16:56] <doko> ari-tczew: what do you win? the version number?
[16:56] <ari-tczew> doko: hmm.. more code?
[16:57] <ari-tczew> maybe merging is something another than we do
[16:57] <mdz> seb128, hmm, the backtrace in 680968 actually seems worse than the old one
[16:57] <mdz> seb128, er, I mean bug 681460 is worse than bug 680968
[16:58] <mdz> in terms of missing symbols
[16:58] <seb128> mdz, yeah, I suck, I just fixed that, I added the ddeb for updates and proposed but the normal proposed source was missing
[16:58] <seb128> mdz, if you try again that should work now ;-)
[16:58] <seb128> mdz, I checked with an apt-cache policy in the retracer this time
[16:58] <mdz> seb128, ok, i'll try again
[17:00] <seb128> mdz, thanks
[17:01] <mdz> seb128, https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/681472
[17:12] <mvo> hey cjwatson - if you have a moment I would like to hear your opinon about bug #670629 - we need to display a eula there and the current pkg just fails if the user refuses. because the package is so popular it will likely cause a lot of failed installs from people runing with noninteractive frontend or just clicking etc. so I was wondering if we should just make it install on refusal but not download the fonts
[17:12] <mvo> cjwatson: my feeling is that the current approach (exit 1) is (much) more correct
[17:12] <mvo> but the amount of dupes to expect is also substantial
[17:13] <seb128> mdz, ok, so it worked this time but you don't get a better stacktrace due to a known retracer "limitation"
[17:13] <superm1> pitti, very cool. and yeah that's a great side effect
[17:13] <seb128> mdz, it cleans all the infos on detected duplicates and it figured you opened a duplicate
[17:13] <mdz> seb128, it was good enough to get it auto-duped, though
[17:13] <mvo> (others are of course invited to comment on this issue too :)
[17:13] <seb128> mdz, right
[17:13] <cjwatson> mvo: your alternative approach sounds OK as long as it's easy to change one's mind (so dpkg-reconfigure should work, apt-get --reinstall install, etc.)
[17:14] <cjwatson> mvo: in fact you could make it quite smooth if dpkg-reconfigure installed or deleted the fonts depending on your answer :)
[17:14] <cjwatson> mvo: it's a bit nasty because dependencies on that package would be made into a lie, but that's OK in this case I think because you aren't supposed to Depends: on local fonts anyway
[17:15] <mvo> cjwatson: thanks, I have similar feelings about it, its not really 100% correct, but will save our users a lot of headache (and the triagers as well)
[17:15] <mvo> cjwatson: I will make it so that depending on the answer the fonts are either downloaded or removed
[17:16] <cjwatson> sounds good to me
[17:17] <mvo> thanks
[17:18] <Laney> how does debian get away with not having the eula?
[17:19] <mvo> Laney: I think in the long(er) run they will have to display it as well
[17:20] <Laney> presumably you'll have to alter the license of the packaging otherwise I could just remove it
[18:39] <micahg> siretart: .YR.MO.X is more common in Ubuntu, +seriesX is more common in Debian for stable updates
[18:40] <geser> cjwatson: re my grub problem: I just noticed that disks are now sdb and sdc (as sda was the usb-stick I booted from). I downgraded grub for now so I can (hopefully) boot without the usb-stick again.
[18:41] <geser> should I repeat the output you requested for sdb and sdc?
[18:42] <cjwatson> geser: I guess so although I don't think it will matter very much
[18:42] <cjwatson> geser: check that the boot loader on your USB stick is still what you expect it to be :-)
[18:45] <geser> the error I got after removing the (md0) and (md1) from the device.map remains
[18:47] <geser> at least the grub.cfg looks like I remember from the past again after the downgrade, so I hope it will boot
[18:52] <cr3> hi folks, I have a package that is mostly python but with some C compilation, so architecture: any instead of all, and when I build in the ppa, I get: /bin/sh: python2.7: not found. any ideas what might be wrong?
[18:52] <geser> cr3: most likely missing python-all-dev in Build-Depends
[18:52] <cr3> geser: will try, thanks
[19:15] <Chipaca> hi all. Is anybody here a moderator of ubuntu-devel?
[19:35] <cjwatson> Chipaca: yes.  I've approved your post
[19:35] <Chipaca> cjwatson: awesome, thank you
[19:36] <Chipaca> cjwatson: why do my emails look so vacuous on https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/032169.html, any idea?
[19:44] <cjwatson> Chipaca: I don't know, sorry.  compare mime structures?
[19:44] <Chipaca> cjwatson: yeah, got to do that i guess
[19:45] <Chipaca> that's what i get from using a version 0.5 mua :)
[19:46] <ajmitch> Chipaca: probably mailman choking a bit when archiving it, it at least looks fine in evolution
[19:47]  * ajmitch is just trying to find out why surveymonkey.com isn't resolving :)
[19:49] <ebroder> Hmm...can anybody point me in the right direction for why plymouth wouldn't be setting the color palette or UTF-8 mode correctly on shutdown when it's running in text mode?
[20:15] <mvo> lool: can you re-push lp:~lool/vmbuilder/fix-run-script-group-perms please? LP/bzr is a bit confused currently, but if you re-push it with a new name it should be fine and then I merge it into vmbuilder
[20:15] <bdrung> ebroder: can you draft an interface for bug #681242?
[20:27] <ebroder> bdrung: Sure
[20:31] <ebroder> bdrung: Do you feel a compelling need for anything more clever than -B/--builder? I'm thinking that maybe the configuration file should be a separate bug (since I can work around that with bashrc aliases)
[20:31] <bdrung> ebroder: maybe a environment variable instead of config file?
[20:32] <bdrung> ebroder: we have already SPONSOR_PATCH_WORKDIR
[20:33] <ebroder> Environment variable works for me
[20:35] <ebroder> bdrung: Commented
[20:46] <lamont> kirkland: is this true that I hear you're trying to sneak byobu-by-default into natty?  DO NOT DO THIS
[20:55] <highvoltage> now onw.
[20:56] <highvoltage> lamont: you mean more than the byoby-enable message that's currently displayed at login?
[20:58] <lamont> highvoltage: byobu's belief that admins log into a machine to monitor it is just one of the many issues I have with that can of c*^*()&9
[20:58] <lamont> and yeah, that
[20:58] <lamont> s part of it
[21:25]  * quadrispro doing a bit of sponsoring
[21:29] <sebner> quadrispro: good to see you, quick question, when I want a dependency on jackd (no b-d, just dependency), which package should I use? jackd, jackd2, ..?
[21:30] <quadrispro> sebner, jackd. It depends on jackd2 | jackd1
[21:31] <sebner> quadrispro: take my thanks :)
[21:31] <quadrispro> you're welcome :)
[21:43] <paissad> hello all, there are some persons who encounter a problem about the start of an init.d script
[21:43] <paissad> they say that the script start before the system gets an ip address, here is the related init.d script
[21:43] <paissad> http://ps3mediaserver.org/forum/viewtopic.php?f=3&t=154&p=39964#p39964
[21:44] <paissad> i thought that the following was enough, why is it not the case ?
[21:44] <paissad> # Required-Start:    $local_fs $remote_fs $network
[21:44] <paissad> and further, is there a workaround ?
[21:44] <paissad> thanks in advance for helping
[22:42] <Volvo> So, nmbd wont run on Ubuntu. Are there any plans to fix it so that SAMBA can work ?
[22:45] <micahg> Volvo: bug 596064
[22:51] <Volvo> It fails to start, Period. Someone has mispatched it ?
[22:53] <Volvo> Its been like this for too long. Is anyone going to fix it ?
[22:55] <Volvo> Works perfectly well if i install the upstream x2 version from source that is, from samba.org
[22:56] <Volvo> Upstream Debian -> Upstream samba.org == x2. Whats really the problem here ?
[22:56] <Volvo> seiflotfy: Hows the media TODAY :)
[22:57] <xnox> Lintian gave me this: warning: collect info objdump-info about package xiphos-dbg failed
[22:57] <Volvo> I guess that if you really want to scare off people from using Ubuntu for servers this is a way to do it.
[22:58] <xnox> should I not be building -dbg packages at all? (this is updating to newer upstream using debian packaging)
[22:58] <Volvo> xnox: YES, because wo those you cant properly debug a package as if at all.
[22:59] <micahg> Volvo: it's assigned, so it's on someone's list, idk about the priority, maybe #ubuntu-server can help
[22:59] <xnox> Volvo, Yes as in "do not build -dbg on Ubuntu, rely on -dbgsym. Do build -dbg package on Debian?"
[23:00] <micahg> xnox: no, you can build it if you want
[23:00] <Volvo> micahg: Show the bug url for the bug you showed because this has been going on for waaaay too long now. I feel a feud of some sort.
[23:00] <micahg> xnox: there are toolchain changes in natty
[23:01] <xnox> micahg, yes toolchain changes. It's just for the first time I see lintian tripping with objdump-info on a -dbg package! BTW xiphos does link agains xulrunner....
[23:02] <RAOF> Volvo: Whereas I look at that bug and see steady progress towards working out what's wrong.
[23:02] <micahg> Volvo: huh?, yes, it's marked as affecting releases back to Lucid, you might want to contact zulcss in #ubuntu-server during Canadian business hours
[23:02] <RAOF> And with patches to test, to boot!
[23:02] <micahg> xnox: I know :), is it compatible with xul20 yet?
[23:04] <xnox> Hmmm =) considering I'm upstream, I'm the first one to upgrade to natty (noone is using f15 either) and I have build problems then I don't think it is =)
[23:04] <Volvo> RAOF: Heheh, whilst id had done it in under 10 hours no matter how bad itd been you mean :) micahg: Thank you very much, ill look into that. Youre very good at what you do and i admire that. Keep up the good work!.
[23:04] <xnox> micahg, will natty ship xul-1.9.2?
[23:04] <micahg> xnox: no
[23:04] <xnox> haha =)
[23:04]  * xnox xiphos is blocking upgrades on xul20 and gtkhtml......
[23:05] <bdrung> xnox: it would help to do the gtkhtml first
[23:05] <micahg> xnox: we  either have to port it or drop it :)
[23:05] <micahg> xnox: BTW, it's not blocking for xul, just needs to be done by March :)
[23:06] <xnox> bdrung, working on it =)
[23:06] <xnox> micahg, either xul20 or webkit =)
[23:06] <bdrung> micahg: don't drop it! you will generate an angry ubuntu user otherwise, who will blame the mozilla team. :p
[23:06]  * xnox sorry to all the xul lovers =)
[23:07] <bdrung> i don't like the xul update policy
[23:07] <micahg> bdrung: 5k by install on popcon
[23:08] <micahg> bdrung: no, we'll try to help if xnox doesn't get to it first
[23:08] <xnox> omg I better hurry =)
[23:09] <xnox> 5k people but that is excluding those who are running xiphos of ppa or including those?
[23:09]  * xnox is amazed. Build finished, back to work.
[23:09] <micahg> xnox: that's only those that have popcon enabled and have ever installed it
[23:09] <bdrung> xnox: i think it includes ppas
[23:11] <bdrung> xnox: 5k popcon ~= 25k (assuming 9M user)
[23:11] <bdrung> xnox: the package with the highest popcon count that i maintain is vlc (778k)
[23:12] <xnox> 8865  libsword8                      10648   939  9263   443     3 (Unknown) for me =)
[23:12] <bdrung> micahg: you failed rounding (5955 -> 6k)
[23:13] <bdrung> oh, we have 12k for gnomesword
[23:16] <xnox> libgtkhtml-editor-3.14.so.0.0.0 is this correct?
[23:16] <xnox> it used to be libgtkhtml-editor.so.0
[23:17] <micahg> xnox: this might be useful: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[23:19] <xnox> "bash upstream with libtool manual" yes i do remember reading that..... long time ago.
[23:19] <xnox> It's just I don't uderstand why they renamed libgkthml-editor now, even though it doesn't build with gtk3 yet =)
[23:20] <micahg> xnox: I have to give you the link because I still don't know exactly how it works :)
[23:21] <Volvo> micahg: There seems to be absolutely no interrest in #ubuntu-server to make any kind of server going.
[23:22] <micahg> Volvo: it's a holiday in the US and evening/night in Europe, so you're not likely to get much of a response right now
[23:23] <Volvo> micahg: Aha, holiday. Im in Europe myself and im mostly online to do what i like best. Code for OSS and answer users questions.
[23:23] <Volvo> Maybe theyre microsofters that doesnt like GNU/Linux ... im just guessing of course.
[23:23]  * micahg has no where to be for the Holiday so just answering queries in IRC :)
[23:23] <xnox> Is 6k users enough to push updates to backports? =)
[23:24] <micahg> xnox: sure, as long as there are no crazy rdepends
[23:24] <Volvo> Thats what good people do.
[23:24] <xnox> Our ppa is very popular but backports can have a wider audience ;-)
[23:24] <Volvo> Microsoft people go to conferences (booring ones) sit there and get bum-rot :)
[23:25] <bdrung> xnox: 1 user would be enough for backports. :)
[23:25]  * micahg is almost an official backporter
[23:26] <bdrung> micahg: i am waiting for the backport natty changes for not installing all backports by default
[23:26] <Volvo> micahg: Be honest, how long have you been packaging for ? / I can help if i wish.
[23:27] <micahg> Volvo: I've been working with packaging for about a year and a half now
[23:27] <xnox> micahg your are awesome =)
[23:27] <Volvo> micahg: Not bad, not bad at all.
[23:28] <micahg> Volvo: I still have plenty to learn
[23:28] <Volvo> micahg: And learn you shall.
[23:28] <bdrung> it's an exponential learning curve :)
[23:28] <xnox> BTW I have just graduated with Electonics Engineering degree MEng. I'd love get into Open-source / linux / with packaging stuff work. But so far I have found just one graduate entry level job in the uk.
[23:28] <xnox> I wish there were more jobs in OSS.
[23:29] <Volvo> micahg: Uni student, private or company etc ?
[23:29] <micahg> xnox: http://webapps.ubuntu.com/employment/
[23:29] <bdrung> micahg: wow, that list got quite long
[23:29] <micahg> Volvo: working for a company
[23:29] <micahg> bdrung: indeed :)
[23:30] <Volvo> micahg: If i look at their frontpage or some subpage i dont see "Microsoft gold partner", right ?
[23:30] <micahg> Volvo: you might...
[23:30] <micahg> actually noy
[23:30] <micahg> *not, but I think they are anyways
[23:31] <micahg> Volvo: my work happens to be with OSS though
[23:31] <Volvo> Hmmz, doesnt mean youre tainted, but if you want you can priv the name and ill look it up.
[23:32]  * micahg wonders if this qualifies for OT
[23:32] <Volvo> Ah! Cool. There are many companies that love OSS
[23:32] <Volvo> For Oh so many reasons or treasons towards them.
[23:32] <bdrung> micahg: do you have time for sponsoring?
[23:33]  * xnox facepalm. I had xiphos in the /usr/local/bin from development........
[23:33] <micahg> bdrung: maybe, I was going to look at the rhythmbox-radio-browser bug
[23:33] <bdrung> xnox: why should a ubuntu developer install something in /usr/local? ;)
[23:33]  * xnox wants bash to print `which $command` if it's not in /usr/bin or /usr
[23:33] <bdrung> micahg: can you look at bug #678283?
[23:34] <micahg> bdrung: sure
[23:34] <bdrung> micahg: thanks
[23:34] <micahg> bdrung: in a bit though?
[23:34] <bdrung> micahg: it doesn't hurry
[23:34] <xnox> bdrung, waf-cache + build + install < 2s. Debuild + dpkg + libeatmydata > 2s
[23:34] <micahg> bdrung: k, I'll do it after dinner
[23:35] <bdrung> xnox: either build a package or build it locally (without installing it)
[23:35] <xnox> right xiphos works fine with new gtkhtml and xul20 =)
[23:35] <xnox> uploading to ppa for testing =)
[23:55] <quadrispro> bye all


[03:20] <jtv> roaksoax: what do I need to do in order to get my tx-tftp fix into the ubuntu package?
[03:25] <roaksoax> jtv: if you want you can file a bug against the package in ubuntu and attach the patch, and I'll take care of it
[03:25] <jtv> Thanks.
[03:26] <roaksoax> jtv: you working todya?
[03:26] <jtv> Nope.
[03:26] <roaksoax> :)
[03:27] <roaksoax> good.. it's been a long weekend for all
[03:28] <jtv> Not for me.  Major internet outage last night.  :(
[03:29] <jtv> I added the Ubuntu package to the bug.   I was wondering if one of the blues is around to take a second look at https://code.launchpad.net/~andreserl/maas/maas_fix_constraints_arch_mapping/+merge/128338.
[10:18] <jelmer> allenap: holding op too :)
[10:18]  * jelmer looks
[10:25] <jelmer> allenap: Sorry, I'm not sure either
[10:25] <jelmer> allenap: the API does seem like the wrong place to be doing this sort of mapping
[10:25] <allenap> jelmer: Okay, I'll leave it as is, and see if John or Martin want to comment. Thanks :)
[10:25] <jelmer> allenap: but I don't think I am familiar enough with this part of the code to give a useful comment
[10:26] <jelmer> allenap: okay; sorry I couldn't be of more help
[10:26] <allenap> jelmer: No worries, thanks for looking.
[13:47] <allenap> Afternoon
[16:13] <roaksoax> allenap: still around?
[16:13] <allenap> roaksoax: Yeah, hi.
[16:13] <roaksoax> allenap: thanks for the review, addressing your comments :)
[16:14] <allenap> Cool, ta.
[16:15] <roaksoax> allenap: comments make sense to you? http://paste.ubuntu.com/1264110/
[16:25] <allenap> roaksoax: Yeah, they're good.
[16:29] <roaksoax> allenap: and I also wnat to wait for the blue squad comments on it since i think they didn't forsee the change of the arch including subarch in maas
[16:29] <roaksoax> and juju passing only arch
[16:29] <roaksoax> allenap: https://code.launchpad.net/~andreserl/maas/fix_ipmi_command_execution/+merge/128358
[16:31] <allenap> roaksoax: Fwiw, I normally only resubmit a merge proposal when I've made a mistake with, say, the prerequisite branch, or the proposal is unrecognisable from before. Ordinarily I just push the changes and ping or comment to alert the reviewer to take another look.
[16:32] <allenap> Although what you did makes sense, it doesn't seem to be the norm.
[16:32] <roaksoax> ok :)
[16:33] <roaksoax> thanks for the advice
[17:03] <allenap> roaksoax: Have a good evening, I'm off now.
[17:03] <roaksoax> allenap: you do as well


[05:23] <pteague> any idea why pressing the mute button gives me a message saying 'mute on' or 'mute off', but i'm still getting audio ?
[05:28] <mrand> pteague: sorry, I don't have any ideas - but most audio problems are a mystery to me.  I'd check the mythbuntu forums... most problems like this are not new.
[05:30] <pteague> yeah, just saw it & hadn't seen it before
[06:29] <foxbuntu> pteague, its because you are not using the internal mythtv audio controls
[06:39] <pteague> is that were i need to go in & set it to alsa:default ?
[06:58] <Technophil> yep
[08:02] <superm1> someone in here was talking about using aptitude for a safe-upgrade... in ubuntu land you shouldn't be using aptitude much..
[08:02] <superm1> you'll run into things like this every so often https://launchpad.net/bugs/499631
[09:45] <Technophil> Jamu seems to run every hour and pull down heaps of stuff from the net each time.  Anyone know where this is controlled - and how can I turn it down a bit, to say once a day?
[10:43] <Technophil> yep in mythbuntu 9.10 its an hourly cron job for anyone interested, not sure its needed to run hourly as it pulls a heap of stuff each hour.
[13:52] <pgee> hey all.  using ubuntu 9.10 on a server (backend) and a laptop (frontend)  used synaptic to install both and i did this today.  why is it i get a version mismatch ?  server is 22982 and frontend is 22594
[13:54] <pgee> hence i get an error mythtv database has new tv schema 1247 than expected 1244.
[14:00] <mrand> pgee: 22594 is the standard repo release... 22982 is a autobuilds.
[14:01] <pgee> mrand  but they don't talk with each other nicely! and they are downloaded from the same package manager.
[14:01] <pgee> !
[14:01] <Zinn> Sorry I don't know about
[14:02] <mrand> Are you sure you enabled the 0.22 version of the mirror/ppa when you installed autobuilds?
[14:03] <mrand> I have to admit I'm more than a bit surprised that they introduced a schema change (I don't recall it, in fact).  It sounds more like 0.23 (aka trunk right now) got selected.
[14:05] <pgee> i used the synaptic package manager.  it says it is version 22594 in the package manager.
[14:06] <mrand> Right.  You'll notice that 22982 is NOT listed there... the only way that you got that installed was by enabling autobuilds
[14:06] <mrand> !autobuilds
[14:06] <Zinn> Auto builds are available for MythTV 0.22 for Intrepid, Jaunty, and Karmic (0.22 and 0.23-trunk).  See http://www.mythbuntu.org/auto-builds for more info.  If you see references to 0.22-trunk, you can ignore the -trunk part :-)
[14:12] <pgee> mrand  i can't see where that autobuilds option is i selected.
[14:13] <pgee> using ubuntu 9.10  if i type apt-get purge mythtv-backend  delete the package from the cache, what do i then do to install the version i want ?
[14:14] <mrand> pgee: can you do the following command and paste the url here?
[14:14] <mrand> apt-cache policy mythtv-frontend | pastebinit
[14:15] <pgee> http://pastebin.com/d76dda9c7
[14:16] <mrand> Sorry - for the other machine with the 22982 version.
[14:17] <pgee> working on it
[14:19] <pgee> http://pastebin.com/d56782c0f
[14:19] <pgee> this is curious
[14:22] <pgee> i never noticed the different svn versions for the front end before.
[14:22] <mrand> Right.  And even more important than the svn version is the word "trunk" right before it.
[14:23] <mrand> That apt-cache is really from that machine?  It makes no sense to me.
[14:23] <pgee> mrand.  i am not sure what that really means.
[14:23] <pgee> yes.  i typed one in after the other.  took a while because i am not physically using that server at the moment.  had to set up a vnc.
[14:24] <pgee> i assume a trunk is a 'higher up' part of the build than a branch ?
[14:24] <mrand> the word trunk means that it is most definitely not running 0.22
[14:24] <mrand> yep
[14:25] <mrand> trunk will eventually become 0.23. It's the development trunk.  0.22 was branched off mid-October and the schema almost never changes on a branch (like 0.22)
[14:26] <pgee> i have been pissing about with this for a few days.  i probably have stuffed it up somewhere.  i am quite happy to completely wipe mythtv and start again. i have done this a few times by using apt-get purge  but i don't know another way to get rid of the source/packages.
[14:27] <pgee> frankly i don't really care for all the new features at the moment.  i just want something that works.
[14:29] <mrand> pgee: understood.  When I'm removing things, I like to use synaptic so that I can easily see what is there or might be left (although search in synaptic is less than perfect, so I typically sort by version) and then I select "complete removal"
[14:29] <pgee> mrand  done that a number of times.
[14:30] <mrand> pgee: including mythtv-database?
[14:30] <pgee> mrand including mysql!
[14:31] <mrand> hehehe... well, ubuntu does a decent job of not deleting config data :-)
[14:32] <pgee> i found where caches were hidden.  rm them as well.  + deleted the mythtv user + removed the .mythtv folder.
[14:32] <mrand> pgee: perhaps you need to drop mythconverg manually.  I thought removing mythtv-database would do it, but perhaps I'm wrong.
[14:33] <pgee> did that using phpmyadmin
[14:33] <pgee> + deleted the mythtv database user
[14:34] <mrand> uh, ok - so it isn't a database problem... it's the mythfrontend that is the problem.
[14:36] <mrand> It's like the /usr/bin/mythfrontend isn't getting removed when you purge or something.
[14:41] <pgee> ok.  i will try once more before bed...  i have  rm -R /etc/mythtv  rm  -r ~/.mythtv  used synaptic to completely remove anything related to mythtv.  dropped the mythconverg database.
[14:42] <mrand> If you type mythtfrontend, does it find anything?
[14:42] <mrand> pgee: ^
[14:43] <pgee> yes. it is!
[14:43] <pgee> working on it now.  used locate mythtv and found loads of stuff left!
[14:44] <mrand> pgee: and synaptic shows nothing in the "installed" version column for mythtv-frontend?
[14:44] <pgee> uh huh.  and yet it is there.  not for much longer... !
[14:45] <mrand> What does apt-cache policy mythtv-frontend show?
[14:48] <pgee> W: Unable to locate package myth-frontend
[14:48] <pgee> i think i remember following some dodgy instrunctions to start with that didn't work.  seems they have caused me no end of problems.
[14:49] <mrand> apt-cache policy mythtv-frontend
[14:50] <mrand> (you forgot the "tv"
[14:50] <pgee> http://pastebin.com/d6ad0a579
[14:51] <pgee> sorry.
[14:52] <mrand> cool.  (none) is the right answer.
[14:53] <pgee> ok.  i have deleted the mythv account. rm /home/mythtv  and deleted loads of other stuff.  try again.
[14:53] <pgee> thanks for your help tonight.
[14:53] <mrand> hehehe  it morning here in Texas
[14:53] <pgee> morning here in tasmania.   2 am that is.
[14:55] <pgee> mrand well i am going to get another beer while that downloads... ;-)
[14:55] <mrand> download a beer!
[14:55] <mrand> hehehe... I'll keep my fingers crossed for ya.
[14:58] <pgee> mmmm beer  http://www.fostersgroup.com/enjoy/beer/D95FC17E050549D78832F6A869F4E2EC.htm
[15:01] <mrand> http://www.shiner.com/main.php?page=beer
[15:05] <pgee> http://pastebin.com/d57d59cc1  definitely time for bed.
[15:07] <mrand> libraries...
[15:08] <mrand> libmyth* in synaptic.
[15:10] <pgee> http://pastebin.com/d4b401fa7
[15:17] <mrand> pgee - idea: if you enable auto-builds, it may overwrite that since autobuilds is using a newer svn checkout.  The only "but" is that it may not install because of a packaing problem that should be fixed on whatever comes after 22994
[15:18] <mrand> I've gotta run for now...
[15:18] <pgee> thanksf or your help./
[15:20] <mrand> Wish we would have fixed it, but I have a minor hope that just installing autobuilds will fix it since the svn checkout is newer.
[15:22] <mrand> another 10 or 12 hours and that new autobuild should be built and ready.
[15:22] <mrand> Ok, I'm off like a prom dress.
[16:36] <quotaholic> Hi all, just downloaded Mythbuntu 9.10 and tried it on my new mac mini in live cd form. I was surprized to see a prompt for a login and password. Despite a few google attempts I cant seem to find what the default login and pass are. Can anyone here help?
[16:45] <tgm4883> quotaholic, that is odd
[16:45] <tgm4883> I'd assume USER: Ubuntu   and no password
[16:46] <quotaholic> I tried that and x reset back to the standard gdm facing
[16:46] <tgm4883> standard GDM facing?
[16:48] <quotaholic> I thought it was odd since only the slack based live distro's usually ask for a password. This took place last night. Let me try again. GDM facing..... By a blanking of the screen and then a reinitialization it seemed like x was resetting and gdm was the next thing I saw. Hense gdm facing. Sorry my terminology is not that of a developer
[16:57] <quotaholic>  Yeah nothing changed. Upon getting past the Mythbuntu splash screen I get dock style bar at the bottom of the screen and a dialog box with the name "ubuntu" and below this a login button. No other options but to press button. After entering informatiion and pressing enter  a sessions menu appears on the "dock" but goes away as credentials did not take and then back to square one. Just seems like I am not using the right lo
[17:51] <MythbuntuGuest18> does anyone know why myth archive keeps failing me and saying "Trying a hard-reset of the device"
[18:52] <bllz> Is there a way to automate the use of myth.rebuilddatabse.pl with metadata grabbed by Jamu?  I don't really care if the recordings I'm adding include an accurate record date... that could be replaced by, say, the original airdate.
[19:13] <lautriv> hi, i miss the option for video-configuration since update from 0.21 to 0.22, anyone a clue ?
[21:51] <Hilikus> hey guys
[21:52] <Hilikus> i need help setting up my RC. i already enabled lirc using MCC but in IRW i don't detect any presses
[23:37] <Hilikus>  what kernel module do i need to be able to use a hauppauge pvr-150 IR Blaster?


[09:49] <LocutusOfBorg> apw, please sync vbox kernel modules :p
[13:19] <jcastro> jsalisbury: if you're around can we talk about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396654 ?
[13:20] <jsalisbury> jcastro, sure
[13:20] <jcastro> oh you're awake, I wasn't expecting that. :D
[13:20] <jsalisbury> heh, yeah.
[13:20] <jsalisbury> jcastro, that is an old bug
[13:21] <jcastro> hey so, the vivid and utopic tags
[13:21] <jcastro> if I wanted to make the case to bring this to $current_animal, how do I do that?
[13:21] <jsalisbury> jcastro, you can just add the xenail, yakkety and zesty tags.
[13:22] <jsalisbury> jcastro, then probably just set the status to "New" instead of triaged or invalid
[13:22] <jsalisbury> jcastro, setting it new makes it pop back up on my radar
[13:23] <jcastro> do I leave the old release tags on there also?
[13:23] <jsalisbury> jcastro, sure, it doesnt hurt anything
[13:24] <jcastro> tags aren't the same as nominating for a series in lp are they?
[13:25] <jsalisbury> jcastro, no, the tags are just used for reports, mail filter and things like that.  Nomimating them for a series is where you would want to set the status to "Invalid" for utopic and other EOL releases
[13:26] <jcastro> oh ok, we'll I messed that up, sorry, heh
[13:26] <jsalisbury> that bug doesn't seem to have any nominations yet, but I can add them
[13:26] <jsalisbury> jcastro, oh nevermind, you did already :-)
[13:27] <jsalisbury> jcastro, I'll take a closer look at that bug today and see what can be done to resolve it.
[13:28] <jcastro> hey so I wanted to convince the guy who was bugging me about it to send a patch
[13:28] <jsalisbury> jcastro, I also added the tag "kernel-da-key".  That makes sure I see and read all email/comments for the bug
[13:29] <jsalisbury> jcastro, yeah, if he already has a patch that would be great
[13:29] <jcastro> he won't use lp or bzr though, this seems like a packaging bug, is there a git workflow?
[13:31] <jsalisbury> jcastro, sure, he can use "git format-patch" and email it to the kernel-team mailing list
[13:31] <jcastro> excellente, I'll encourage him to do that
[13:31] <jsalisbury> jcastro, great
[13:32] <jcastro> I was blindsided by "hey you guys haven't fixed this bug in 3 years" and I was like dang, at least try to ask somebody
[13:32] <jsalisbury> jcastro, heh, yeah.  bugs usually expire after 6 months if there is no activity
[13:32] <jcastro> right
[13:33] <jcastro> also my "I thought mangled was the entire point of C++" probably didn't go over well lol.
[13:33] <jsalisbury> haha
[13:33] <Vej> Hello! Could someone with knowledge about the kernel update process point Simon Davis (and me) to a resource about inclusion of that fix into the upstream stable. I run out of knowledge and manuals. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1663991
[13:35] <jsalisbury> Vej, I'll add a comment
[13:35] <Vej> jsalisbury: Thank you very much!
[13:35] <jsalisbury> np
[13:43] <jcastro> jsalisbury: in hindsight, https://wiki.ubuntu.com/Kernel/Dev/KernelPatches is awesome
[13:43] <jcastro> I wish I would have found that first
[13:44] <Vej> jsalisbury: I am sorry, but that left more questions to me than clarifying things. That patch is already accepted into 4.10.1 (see https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a810007afe239d59c1115fcaa06eb5b480f876e9). Do we need to submit it again to get it integrated into  4.4.X, or will you cherry-pick/include from 4.10.1?
[14:38] <jtaylor> is it possible to add some kind of automated test for bug 1396654? quite annoying having it break every few releases


[07:44] <pnorman> I'm starting work on packaging some software in a PPA, but don't currently have a Debian-based machine free. What OS and version would I be best off installing to do this work?
[17:30] <wxl> can anyone tell me why a ppa isn't giving hme the latest version
[17:30] <wxl> ?
[17:30] <wxl> namely ppa:ubuntu-mozilla-daily/ppa and thunderbird-trunk
[17:30] <wxl> i seem to be stuck on 38.*
[17:30] <wxl> version table is telling me that's the latest version
[17:31] <wxl> i've tried removing and reinstalling the repository
[17:47] <dobey> ask the owner of the ppa why it doesn't have the latest version i guess
[17:48] <dobey> wxl: seems the later versions have had some problems building
[17:49] <dobey> not an issue with launchpad itself
[17:49] <wxl> yep dobey
[17:50] <wxl> thx


[00:08] <cjwatson> infinity: Hah!  rakudo/armhf finally stuck to the wall
[00:08] <cjwatson> On about the fourth or fifth try
[00:09] <cjwatson> Not totally reassuring, but ...
[00:13] <infinity> cjwatson: Haha.  Seriously?
[00:13] <infinity> cjwatson: Good job clicking retry, I guess?
[02:14] <slangasek> cyphermox: do you happen to know how to make dnsmasq answer bootp (not dhcp) requests?
[02:14] <cyphermox> not by memory
[02:14] <cyphermox> I suspect it's hidden somewhere in its monstrous manpage
[02:14] <slangasek> cyphermox: is this configurable via dnsmasq.conf, or only by commandline?  (I find a -M option on the commandline)
[02:14] <slangasek> heh
[02:14] <cyphermox> both
[02:15] <cyphermox> -M, --dhcp-boot=[tag:<label>,]<nom de fichier>,[<nom de serveur>[,<adresse de serveur>|<nom du serveur tftp>]]
[02:16] <cyphermox> (sorry, in french)
[02:16] <slangasek> ah, looks like my root problem may be not using --bootp-dynamic
[02:16] <cyphermox> but basically you'd use the long option name with the seetings
[02:16] <cyphermox> ah
[02:16] <slangasek> I think
[02:16]  * cyphermox is playing with quagga, doing a presentation on advanced networking config in Quebec city tomorrow
[02:18] <slangasek> I'll trade you that for getting grub2 to pxe boot under efi ;)
[02:18] <cyphermox> wooo
[02:18] <slangasek> right, got an address from bootp now
[02:18] <slangasek> that's progress
[02:18] <cyphermox> can I help? my desktop is setup with efi already
[02:19] <slangasek> cyphermox: sure; grab http://archive.ubuntu.com/ubuntu/dists/quantal/main/uefi/grub2-amd64/current/gcdx64.efi.signed, pxe boot it, and see if you can teach it to find any other files over pxe ;)
[02:19] <cyphermox> by grub2 to pxe boot, you mean using whatever commands are available in grub to grab a kernel somewhere, or is it something else?
[02:19] <slangasek> s/pxe/tftp/
[02:19] <slangasek> not just the kernel, but also the grub.cfg
[02:19] <cyphermox> fun.
[02:20] <cyphermox> that might actually be something fun to demo tomorrow, too
[02:20] <slangasek> if you manage to get this working for tomorrow, I'm buying the beer in CPH :)
[02:24] <cyphermox> haha
[02:25] <cyphermox> doesn't grub need to be looking for some variable (dhcp option or whatever) to know where to get the grub.cfg?
[02:25] <slangasek> that's part of the challenge! :)
[02:25] <slangasek> at this point, I'm just trying to get to where grub is reading files from tftp
[02:28] <cyphermox> ok
[02:28] <cyphermox> I think the option thing might be 209
[02:29] <slangasek> that seems to be an option particular to pxelinux
[02:36] <slangasek> option 17 is "root path"
[02:36] <slangasek> and grub parses this
[02:37] <slangasek> there's also an "extensions path"
[02:37] <slangasek> (option 18)
[02:45] <cyphermox> NBP is too big to fix in free base memory
[02:45] <cyphermox> oops
[02:53] <slangasek> heh, and that's just the bootloader
[02:55] <cyphermox> getting farther
[02:55] <cyphermox> slangasek: what is the difference between that grub file and efilinux.efi?
[02:55] <slangasek> cyphermox: the fact that it's grub, not efilinux
[02:55] <cyphermox> good answer ;)
[02:55] <slangasek> and thus is likely to actually support tftp after :)
[02:56] <cyphermox> well, seems to be too big for my device to allow loading it
[02:57] <cyphermox> unless it's just because it's not passing the file size
[03:00] <cyphermox> .. in 512byte blocks
[06:18] <slangasek> cyphermox: looks like dnsmasq doesn't send a magic value at the start of the vendor section of the bootp packet that grub is counting on
[06:58] <Whoopie> Hi, I enabled the proposed repository some time ago. I just recognized that two packages (language-pack-de-base and language-pack-gnome-de-base) are held back for a longer time as they are not installable. So my question is when new language packages are pushed to the proposed repo.
[07:45] <obounaim> Good morning.
[11:18] <doko> cjwatson, infinity: java3d - adding "-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed" should help. you are missing -shared when replacing ld with gcc and linking a shared lib. and drop the explicit -lc. see scheat:~doko/tmp
[18:20] <RobOakes> Does anyone know the best channel to ask Ubuntu related packaging questions in?
[18:20] <lifeless> #ubuntu-packaging ?
[18:20] <RobOakes> lifeless: Thanks, that makes good sense.
[20:38] <espirit> Hello. There are no available drivers in "Additional Graphics" tab for my ATI Radeon HD Mobility Graphics card (4xxx). Is this a bug?
[20:39] <espirit> but they were available in jockey in 12.04
[21:03] <ScottK> espirit: Make sure you have the latest as there was a bug that might affect that fixed yesterday.
[21:06] <espirit> Yes. Just ran an update manager. But still no available drivers.
[21:14] <ScottK> Not sure what's supported for ATI this cycle.  You might ask in #ubuntu-x.
[21:15] <espirit> ScottK: Ok. Thank You.
[21:45] <rmk> Hi guys.  What's the "pool" structure used for within the archives?
[21:46] <rmk> I need to setup a local mirror of selected versions and am figuring out what I need
[21:50] <SpamapS> rmk: the pool structure is just how the .deb files are arranged by default..
[21:51] <rmk> So I don't necessary need to mirror it for use by apt, right?
[21:51] <lifeless> apt-ftparchive is your friend
[21:51] <lifeless> or one of the mirror tools
[21:52] <SpamapS> rmk: right, something like  apt-ftparchive relative/path/to/debs http://yourmirror/docroot/that/leads/there
[21:52] <SpamapS> rmk: that will spit out a Packages file
[21:54] <SpamapS> rmk: man apt-ftparchive .. its a big man page, but a pretty straight forward process
[21:54] <rmk> OK thanks.  Yeah I was planning to use rsync initially.
[21:55] <SpamapS> rmk: if you just want a full mirror, then there are many ways to get that done: https://wiki.ubuntu.com/Mirrors#Mirror_Guidelines
[21:56] <rmk> Right I read that page but I'd rather not mirror 600GB or whatever, when I need a fraction of it (oneiric, precise)
[21:57] <SpamapS> rmk: apt-mirror makes that pretty easy
[21:58] <rmk> Yeah this looks handy, thanks for the tip