[00:01] <cjwatson> jdong: don't know, please try with ubiquity --debug and send me /var/log/syslog and /var/log/installer/debug (before rebooting)
[00:01] <jdong> ok, will do
[00:34] <Bsims> Is there a way to automaticaly tell apt/synaptic to automatically download all -dev packages for all libraries?
[00:35] <robert_ancell> does anyone know the safe way to compile with warning flags (-Wall etc) in automake.  i.e. that will work with other compilers?
[00:38] <cjwatson> robert_ancell: see man-db/m4/man-gcc-warning.m4 for one possible approach
[00:38] <robert_ancell> cjwatson, thanks
[00:39] <cjwatson> robert_ancell: actually, there's a more polished version in gnulib, gl_WARN_ADD
[00:39] <cjwatson> m4/warnings.m4
[00:42] <Bsims> Is there a way to automaticaly tell apt/synaptic to automatically download all -dev packages for all libraries? I build some things from source and it would save the ./configure, growl, apt-get, repeat dance
[00:43] <RAOF> Bsims: There is not, but have you tried “aptitude build-dep $PACKAGE”?  For packages in the archive that will get you all the necessary dependencies.
[00:43] <johanbr> Bsims, you could try "sudo apt-get install $(dpkg -l |awk '$2 ~ /.*-dev$/{print $2}')"
[00:43] <RAOF> It would be a relatively easy thing to script if you really wanted to, though. johanbr's one liner is a good start.
[00:43] <Bsims> RAOF: its not in the archive is the problem
[00:44] <Bsims> johanbr: Yeah I thought something like that
[00:44]  * Bsims grins now what I'd love to bluesky is a metapackage or option to synaptic/Ubuntu Software Center for that
[00:49] <Bsims> Thanks
[01:13]  * hallyn needs an ubuntu install cd to install on his 10 year old laptop that won't boot usb :)  drat, cds are so 5 years ago that i have no blanks
[01:54] <mathiaz> smoser: hey!
[01:54] <mathiaz> smoser: I looked at the landscape-client SRU - it's already been uploaded to -proposed
[01:55] <smoser> ugh
[01:55] <smoser> sorry to have wasted your time
[01:55] <smoser> when was it uploaded ?
[01:55] <mathiaz> smoser: however it still sits in the queue because one of the bug is not a proper SRU
[01:55] <smoser> ugh.  it would have been nice if someone would have mentioned that in the bug rather than just ignoring
[01:55] <mathiaz> smoser: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
[01:56] <mathiaz> smoser: it actually is mentioned in the bug 597000
[01:57] <mathiaz> smoser: https://bugs.launchpad.net/landscape-client/+bug/597000/comments/4
[01:57] <mathiaz> smoser: so I've assigned free from the landscape team to look at that
[01:57] <mathiaz> smoser: and turn the bug into a proper SRU
[01:57] <mathiaz> smoser: the issue comes from the fact there were 2 uploads to -proposed
[01:57] <smoser> yeah.
[01:57] <smoser> sorry.
[01:58] <smoser> i was just sheparding :-(
[01:58] <mathiaz> smoser: which always makes things a little bit more complicated
[01:58] <mathiaz> smoser: I understand - no worries ;)
[01:58] <ScottK> Laney: Anyone can set verification done.  To the extent you find the wiki confusing on this point, please fix it.
[02:23] <poolie> that would make us doll-wigglers
[02:23] <lifeless> QA is hard, lets drink beer.
[02:23] <RAOF> They're actually absolute imports; simply dropping the leading ‘.’ works fine.
[02:23] <RAOF> poolie: I'm OK with that, as long as they're daemonic dolls.
[02:24] <poolie> i think there should be no dot there
[02:24] <RAOF> It *does* work without the dot, yes.
[02:25] <poolie> wow it's all over the place
[02:25]  * RAOF didn't find an upstream bug before moving on to other things.
[02:26] <RAOF> Yeah.  All the imports are faux-relative.
[02:26] <RAOF> I should probably have documented that on the bug. :)
[02:26] <poolie> perhaps upstream tested it from inside a source directory so it found a different module
[02:26] <poolie> though that still doesn't seem like it would work
[02:26] <poolie> oh, perhaps i duped your bug?
[02:26] <poolie> i just filed this one
[02:27] <poolie> i also filed https://bugs.edge.launchpad.net/ubuntu/+source/hamster-applet/+bug/600855 but it may have the same root cause
[02:27] <RAOF> Yup.  They'll have the same root cause, and are both duplicates of…
[02:27] <poolie> what's worse is without hamster i can't track how much time i'm spending on this yak :-)
[02:29] <RAOF> :)
[02:29] <RAOF> Ah.  Of bug #599654, which apport has helpfully marked private.
[02:31] <RAOF> Hm.  According to bug #596072 it works in git master?
[02:35] <poolie> i wonder if we have an import branch
[02:35] <RAOF> Shall I leave you to work out what's what?  I can upload if you need a fix sponsored.
[02:35] <poolie> ok
[02:39] <poolie> those import statements still seem to be present in our branch of it
[02:39] <lifeless> merge-upstream time probably
[02:40] <poolie> i mean in our import branch of their master branch, which seems to be up to date
[02:40] <lifeless> oh
[02:42] <lifeless> http://www.python.org/dev/peps/pep-0366/
[02:43] <lifeless> http://www.python.org/dev/peps/pep-0328/ is the main relative import PEP
[02:55] <poolie> yay, fixed
[02:56] <RAOF> Huzzah!
[03:04] <poolie> raof can you take it from here? sponsor an upload or something
[03:04] <RAOF> poolie: Absolutely.  Where's the fix?
[03:05] <poolie> https://code.edge.launchpad.net/~mbp/ubuntu/maverick/hamster-applet/600857-imports/+merge/29046
[07:03] <pitti> Good morning
[07:03] <dholbach> good morning
[07:03] <ajmitch> hi
[07:03] <poolie> hi there
[08:09] <ricotz> pitti, good morning, please don't care about if i am opening this bug again this isnt an ubuntu bug and slipped into the changelog https://bugs.edge.launchpad.net/docky/+bug/504486
[08:09] <pitti> ricotz: ah, ok; no problem
[08:09] <pitti> I just thought it was an oversight, since "incomplete" for a fixed bug seems strange
[08:12] <ricotz> pitti, yes and this bug is a bit strange, thanks for accepting docky
[08:12] <pitti> thanks for all the testing
[08:22] <dupondje> Some archive admin that can accept https://bugs.launchpad.net/ubuntu/+source/opal/+bug/600121 ?
[08:23] <mvo> cjwatson: I had a "unaligned pointer 0xxxxx" error this morning in maverick at boot, I fixed it via grub-install /dev/sda. I don't boot the system often so I can not say with 100% certainty what version may have caused it. let me know if I should provide more info or a bugreport please
[08:25] <pitti> lool: (reading liblauncher-0.1 changelog); we don't need a quilt b-dep for 3.0 packages
[08:26] <lool> pitti: Oh right
[08:27] <lool> pitti: Pushed to lp:ubuntu branch
[08:28] <pitti> not a biggie, but merci
[08:34] <dupondje> dholbach: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569077
[08:35] <dholbach> dupondje: is debian upstream for that package?
[08:35] <dholbach> dupondje: or who is the author of it?
[08:35] <dupondje> linuxtv itself
[08:35] <dupondje> going to check to make a bugreport there
[08:35] <dholbach> thanks a bunch dupondje
[08:49] <cjwatson> mvo: debconf-show grub-pc | grep install_devices
[08:51] <mvo> cjwatson: http://paste.ubuntu.com/458198/
[08:54] <cjwatson> mvo: and no dialog on upgrade or anything?
[08:55] <cjwatson> mvo: that's very odd, it ought to have run grub-install for you
[08:55] <mvo> cjwatson: let me check my log, I don't reboot the machine much, its quite likely that this happend a couple of days ago, I did however upgrade to the latest grub-pc this morning (before grub-install /dev/sda) and got no dialog and no fix
[08:55] <mvo> cjwatson: let me check the apt/term.log
[09:01] <mvo> cjwatson: here is what I have in the logs related to grub http://paste.ubuntu.com/458201/ - I can upload the full logs too if that is helpful
[09:28] <cjwatson> mvo: ah, this is Debian #586143 then
[09:28] <cjwatson> mvo: as in, same cause - you have leftovers of a GRUB Legacy upgrade still around
[09:28] <cjwatson> mvo: next upload will fix it, so just don't do anything for now and you can test that process :-)
[09:29] <cjwatson> mvo: mind you, having lupin-support installed probably isn't helping either - is this a Wubi install?
[09:31] <mvo> cjwatson: ok, I will not touch it and wait for the next upload :) the lupin thing is a leftover from a hardy->lucid upgrade issue triggered by lupin (the infinite loop bug)
[09:32] <mvo> cjwatson: I installed it then to check it out but forgot to remove it again
[09:58] <cjwatson> mvo: lupin-support is harmless, actually, looking at it
[09:58] <cjwatson> it does divert grub-install, but the diversion just chains through to the real one if wubildr doesn't exist
[10:12] <ogra> does anyone know from the top of their head where udevd writes its queue file ?
[10:12]  * ogra would suspect in /dev 
[10:13] <ogra> ah, seems like /dev/.udev/
[10:50] <apw> do i detect a rebuild test in progress (from the length of the PPA queues) ?
[10:58] <geser> apw: yes, a test-rebuild is in progress (https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20100628/)
[11:01] <ogra> cjwatson, could you promote the linux-ti-omap4 metapackage to main ? seems it landed in universe
[11:01] <ogra> (though i'm not really happy with the naming, should rather be just linux-omap4)
[11:07] <cjwatson> ogra: done
[11:07] <cjwatson> need to sort out omap4 seeds, mind you
[11:07] <ogra> we have subarch specific seeds ?
[11:08] <ogra> you nean it needs to be added to the installer seed etc ?
[11:08] <ogra> *mane
[11:08] <ogra> gah
[11:08] <ogra> *mean
[11:10] <cjwatson> that wasn't what I meant, although the versions in the installer seed need to be updated
[11:10] <cjwatson> how about I take care of it, since I know what I mean :)
[11:10] <cjwatson> easier to do than to explain
[11:11] <ogra> yeah
[11:12] <cjwatson> ogra: do you know why there are no udebs for the new linux-ti-omap4 package?
[11:12]  * ogra fixes livecd-rootfs ... i went with the wrong assumption the metapackage would follow our naming scheme 
[11:12] <cjwatson> uh, maybe that's wrong
[11:12] <cjwatson> linux-ti-omap4 | 2.6.34-901.2 |      maverick | source
[11:12] <cjwatson> linux-meta-ti-omap4 | 2.6.35.900.1 | maverick/universe | source
[11:12] <cjwatson> is something out of sync?
[11:12] <pitti> mr_pouit: uploaded xfce4-session to xubuntu-dev PPA with another piece of halsectomy, FTR
[11:12] <ogra> i dont think so, there was only one upload
[11:13]  * ogra checks deps
[11:13] <cjwatson> linux-meta-ti-omap4 (2.6.35.900.1) maverick; urgency=low
[11:13] <cjwatson>   * Maverick ABI 900 (2.6.34-900.1)
[11:13] <cjwatson> this is, to say the least, odd
[11:14] <cjwatson> and the autogenerated dependencies are of course on 2.6.35
[11:14]  * cjwatson suspects a difficult-to-fix foul-up
[11:16] <ogra> hmm, yeah
[11:16] <cjwatson> if I'm understanding this correctly, and you want to change the package names anyway, now would be a good time to do it. :-)
[11:16] <cjwatson> that'll be easier than trying to roll back the version
[11:17] <ogra> yeah
[11:17] <ogra> the binary should really be linux-omap4
[11:17] <ogra> to match with all other packages
[11:17] <mr_pouit> "Monkey-patch" huhu pitti, nice. I'll test that this evening ;)
[11:17]  * apw notes that these packages were uploaded 10 days ago, and you are checking them after the freeze ... 
[11:17] <ogra> the versioning might have been done with a view on the future
[11:18] <ogra> since the omap4 branch will end up at 2.6.35 before kernel freeze
[11:18] <apw> ogra, normally we'd not do that, i suspect its a typo
[11:18] <apw> typo
[11:18] <ogra> apw, ok
[11:18] <apw> as 34 is < .35 anyhow
[11:18] <ogra> apw, could i get a fix for both issues ? :)
[11:18] <pitti> mr_pouit: in the sense that I only changed as little as necessary
[11:19] <pitti> mr_pouit: i. e. error messages will still talk about "HAL" :)
[11:19] <pitti> mr_pouit: but it works great here, tested suspend, reboot, and shutdown; hibernate properly says "not enough swap space" (I don't have swap in that project)
[11:19] <ogra> apw, which freeze are you referring to ?
[11:20] <apw> alpha-2 ?
[11:20] <ogra> we dont even have omap4 images :)
[11:20] <ogra> so A2 didnt matter
[11:20] <apw> ahh tahts ok then
[11:20] <ogra> i'm just starting to roll the first set
[11:20] <ogra> or planned to start when i found the odd stuff :)
[11:21] <m4t> hey, i've been working for a few hrs to get plymouth working on a custom kernel, and i got it finally working with KMS enabled on radeon...but now GDM doesn't appear. it just stays at the ubuntu logo, though gdm and X are supposedly running. is this a simple fix?
[11:21] <pitti> mr_pouit: updated https://wiki.ubuntu.com/Halsectomy, too
[11:21] <cjwatson> apw: alpha-2 was released yesterday :)
[11:22] <ogra> yeah, that too :)
[11:22] <m4t> i killed it and now its accessible
[11:22] <apw> cjwatson, although there the binary packages are the wrong name, the source package is actually correct, so to 'fix' this i'd be wanting to upload an older version ... is that even possible ?
[11:22] <cjwatson> apw: it's not possible
[11:22] <ogra> smeels like epoch
[11:22] <cjwatson> apw: either epoch, or rename the source package
[11:23] <cjwatson> (and check that your scripts work with an epoch, if the former)
[11:23]  * apw whines
[11:23] <ogra> apw, i'd go with a new source package, just frop the ti
[11:23] <ogra> *drop even
[11:23] <cjwatson> apw: if you can't rename, then this is what epochs are for
[11:23] <apw> cjwatson, yeah ... but they are evil
[11:24] <ogra> there is not really a reason to point to the vendor in the package name ... there wont be other manufacturers producing OMAP
[11:24] <apw> ogra, well we have a standard naming scheme for our source packages
[11:24] <apw> and only this odd naming scheme for the binaries cause the installer was difficult
[11:25] <apw> so to be inconsistent would be annoying
[11:25] <cjwatson> apw: no they're not
[11:25] <ogra> linux-meta-ec2 ?
[11:25] <cjwatson> apw: they're evil if Debian doesn't have an epoch
[11:25] <cjwatson> apw: in that case, we're dooming ourselves to unsyncability forever
[11:25] <cjwatson> apw: but that's not relevant here, so an epoch is the right technical tool for the job
[11:25] <ogra> linux-lpia-meta ...
[11:26]  * apw cannot see the last one :)
[11:26] <ogra> heh
[11:26] <apw> all our vendor branches are named the same, and the source packages match them
[11:26] <ogra> well, then go with epoch
[11:26] <ogra> was just a suggestion to easily avoid adding one
[11:27] <ogra> though i dont know what an epoch imples for the M+1 release where omap4 is supposed to end up in the mainline branch
[11:28] <apw> ogra, yeah ... i really don't want to find out all the nastyness that an epoch would produce either
[11:28] <apw> if we know we are definatly going to be getting a .35 based before release we can probabally just 'fix' the meta packages for the moment
[11:28] <ogra> it might force you to add an epoch linux-meta for upgradeability reasons
[11:29]  * apw will talk to tim, and get a plan together ... what a pain
[11:29] <ogra> though linux-meta seems to break your naming scheme :)
[11:29]  * ogra giggles
[11:29] <ogra> there is linux-omap
[11:29] <apw> yeah the binary packages should be linux-flavour
[11:29] <ogra> yeah
[11:30] <apw> that is a bug also
[11:30] <ogra> thats the one i'm more intrested in actually
[11:30] <apw> well the version not pointing to the right place isn't going to win us awards
[11:30] <cjwatson> an epoch in linux-meta would hardly be the end of the world
[11:31] <ogra> linux-meta-ti-omap4 | 2.6.35.900.1 ... you could just keep bumping the minor version there until the actual image is at .35
[11:31] <ogra> but indeed thats extra work to maintain it
[11:31] <cjwatson> certainly you could sed s/2\.6\.35/2\.6\.34/ in debian/rules for a while
[11:31] <apw> ogra, indeed, but it might be the easiest course
[11:31] <cjwatson> er fix syntax to work
[11:31] <apw> cjwatson, exactly my thought
[11:31] <ogra> yeah
[11:31] <apw> as we know it will be .35 in the end
[11:31] <m4t> okay that was happening i guess because of the dkms enable parameter i passed to radeon.ko
[11:32] <apw> bah humbug ... ogra thanks for the heads up
[11:33] <ogra> apw, thanks for taking care :)
[11:33] <m4t> i only have one other question. i applied 0001-trace-add-trace-events-for-open-exec-an.patch and enabled CONFIG_FTRACE=y and CONFIG_ENABLE_DEFAULT_TRACERS=y. ureadahead will write to /var/lib/ureadahead if i run it after say, doing 'find /'
[11:33] <m4t> but at boot it writes nothing. is there some way to debug it? perhaps have it log to a file?
[11:36] <apw> m4t, you have to remove the pack to triger it to make a new one
[11:37] <m4t> yep there is no pack, and i even tried creating a 0 length one with a > 1mo timestamp
[11:37] <m4t> i also tried changing /etc/init/ureadahead.conf to also use '--force-trace'
[11:38] <apw> as this is a personal kernel have you tested ftrace works even?
[11:38] <m4t> pretty sure it works because i ran ureadahead -v after stat()ing a whole bunch of files with find
[11:38] <m4t> and i got flooded with messages about things that came up in /proc not being regular files
[11:39] <apw> then its a little odd its not working on boot for you then
[11:39] <apw> nothing other than the kernel is be-spoke ?
[11:39] <m4t> nope
[11:39] <m4t> only reason i'm running a newer kernel is for pax patch
[11:40] <m4t> newer/custom
[11:40] <m4t> and i've got pax disabled on the ureadahead binary
[11:43] <m4t> if i do ureadahead -v, run find /usr, and then ^C it definitely appears to work, and write to /var/lib/ureadahead
[11:43] <m4t> see 'pack' itself and various *.pack files for my partitions
[11:43] <apw> m4t, and have you confirmed it is even run on boot ?
[11:43] <m4t> apw ;-)
[11:44] <apw> is that a yes?
[11:44] <m4t> i see it in boot.log
[11:44] <m4t> well i mean i haven't truely confirmed
[11:44] <m4t> but it does have messages there
[11:44] <apw> i would be tempted to move it to ureadahead.real and add  a wrapper that records it being run
[11:44] <apw> and see hwat params it gets
[11:45] <m4t> i will try that
[11:55] <m4t> it definitely does run
[11:55] <m4t> i was in single user. the only thing i thought might be happening is ureadahead opening a file on ROOT/var rather than my separate var partition
[11:55] <m4t> i wasn't able to unmount var to investigate though
[11:57] <m4t> no thats definitely not whats happening, i checked
[11:58] <m4t> about all i found out is that ureadahead runs, and returns 0 to the shell
[12:01] <m4t> oh duh, well https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/523484
[12:01] <directhex> Subject: 	libgdiplus_2.6.4-1_source.changes rejected
[12:01] <directhex> libgdiplus is a mono package, can i please have upload rights on it?
[12:01] <m4t> maybe i can create the directories manually on /
[12:02] <Laney> directhex: ping cjwatson to get it added to the set
[12:02] <m4t> ah i see a great solution actually
[12:02] <Laney> (I guess that just did it)
[12:02] <directhex> cjwatson is conveniently awake
[12:03] <m4t> have '/'var/lib/ureadahead be a symlink to '/'.ureadahead
[12:05] <cjwatson> sure
[12:12] <m4t> yes the smlinks work, i definitely have the pack files in /.ureadahead now
[12:12] <m4t> apw thanks
[12:13] <m4t> im going to update that to make sure that /.ureadahead/debugfs is created, else it won't work
[13:02] <apw> cjwatson, which meta package does the installer use?  or is it a direct linkage
[13:04] <cjwatson> apw: normally the top-level one if it can, i.e. linux-<flavour>
[13:04] <cjwatson> though it falls back to linux-image-<flavour>
[13:05] <apw> so does that mean its important that the linux-<flavour> matches the linux-image-*-<flavour> ?
[13:06] <cjwatson> you mean whether the two <flavour>s are textually the same?
[13:07] <apw> yeah do they need to be the same ?
[13:07] <cjwatson> no, the installer doesn't care
[13:07] <cjwatson> linux-<flavour> can depend on apw-is-god-let-all-earth-adore-him for all it cares
[13:08] <cjwatson> (though you might have a slight archive admin issue there)
[13:08] <apw> heheh i bet
[13:33] <directhex> cjwatson, is there an email address or something i should ping to formally request a change to the cli-mono package set?
[13:34] <cjwatson> directhex: no need, I just got distracted - done now
[13:34] <directhex> ta
[13:41] <directhex> Subject: 	[ubuntu/maverick] libgdiplus 2.6.4-1 (Accepted)
[13:41] <directhex> woo
[14:33] <apw> ogra, ok its in the queue, but the buildd's claim it won't start until the 5th
[14:34] <apw> ogra, not that that makes much sense as the queue is only 8 hours long
[14:36] <hallyn> james_w: hi - could you port the seabios package into bzr?
[14:38] <james_w> hallyn: it's already done: https://code.launchpad.net/ubuntu/+source/seabios
[14:38] <hallyn> james_w: dude!
[14:38] <hallyn> thanks :)
[14:39] <hallyn> (i swear i checked that!)
[14:41] <cnd> james_w: would you be able to take a look into why xorg-server package releases for maverick are not getting pushed into the bzr branch?
[14:41] <hallyn> kirkland: so i guess i'll do a merge request through bzr instead
[14:58] <ogra> apw, all fine, it built
[14:58] <apw> ogra, how did that happen, those estimates are all mad
[14:59] <ogra> the queue doesnt know how long a package actually builds so it assumes worst case if all builders are occupied i think
[14:59] <ogra> apw, if you have such a case you can ask a buildd admin to bump priority btw
[14:59] <apw> ogra, hrm, i thought it built an average time for each package
[14:59] <pitti> I think it does know (roughly) how long a package will need
[14:59] <pitti> I guess it looks at the build time of the previous version
[15:00] <apw> pitti, seems to be all out of wack today, was saying 3days, yet it built in minutes
[15:00] <pitti> maybe that's broken for PPAs
[15:00] <apw> Can't open average time db /var/debbuild/avg-build-times
[15:00] <apw> Can't open average space db /var/debbuild/avg-build-space
[15:00] <apw> pitti, this was a main buildd build, going into maverick
[15:01] <apw> but i suspect that they may be broken
[15:01] <pitti> apw: hm, where does it say 8 hours?
[15:01] <pitti> main buildds are rather empty, except doorstopper archs
[15:02] <apw> pitti, when i submitted the upload, it said it was going to start on the 5th, so i looked at the queue /builders/ and it said 8 hours, and then the job itself ran about 20 mins later
[15:02] <pitti> fun
[15:02] <apw> something isn't quite right with its head
[15:02] <pitti> apw: it's just too hot outside
[15:02] <apw> cirtainly is here :)
[15:03]  * pitti looks forward to the weekend, which he will spend with tenting, swimming, reading, idling, BBQ, and watching the soccer game
[15:21] <apw> pitti, sounds like a dream
[15:21] <apw> i am seeing builds failing "failed to upload" in the rebuild test
[15:22] <apw> is that normal, or something i should report
[15:22] <apw> ogra, are those new meta packages looking a bit better?
[15:52] <apw> cjwatson, did the linux-meta-omap dissappear from maverick in the end ?
[15:54] <mvo> DktrKranz: hi, just wanted to let you know that I updated gdebi to use python-apts debfile and python-apt now has all the features that were missing (kiwinote did a good chunk of this porting)
[15:54] <mvo> DktrKranz: I'm pretty happy about this :)
[15:55] <DktrKranz> mvo: a-ha! cool :)
[15:55] <mvo> plus improved testsuit for debfile.py as a added bonus (the gdebi test-debs) :)
[15:55]  * mvo feels like after a spring cleanup
[15:56] <DktrKranz> some older code has already been dropped, gdebi's lifting \o/
[15:56] <mvo> yeah :)
[15:57] <mvo>  11 files changed, 42 insertions(+), 238 deletions(-)
[15:59] <cjwatson> apw: linux-meta-omap is gone, although there's still a linux-meta-ti-omap source package building no binaries
[16:00] <cjwatson> apw: I could use a bug report with ubuntu-archive subscribed to it explaining what the desired state is
[16:01] <apw> cjwatson, yep can do that
[16:01] <cjwatson> thanks
[16:13] <ogra> jdstrand, could you let linux-omap4 oput of NEW ?
[16:13] <ogra> *out
[16:13] <ogra> (it changed its binary name)
[16:15] <apw> cjwatson, i've assigned ubuntu-archive to bug #595949 which was the bug under which we fixed the linkage in linux-meta, i've added a full descrtiption of the change and what I think is required in the last comment
[16:16] <apw> s/assigned/subscribed
[16:18] <mdeslaur> ogra: jdstrand is on vacation
[16:19] <ogra> mdeslaur, hmm, you dont happen to know who does his archive admin duties on fridays ?
[16:20] <mdeslaur> ogra: no, sorry
[16:23] <ogra> so since jdstrand is on vac. could some other archive admin please let linux-omap4 out of NEW ?
[16:36] <ari-tczew> kirkland: ping
[16:36] <kirkland> ari-tczew: hi
[16:37] <ari-tczew> hi kirkland, is it possible contribute to Debian first for byobu and syncs to Ubuntu then?
[16:38] <kirkland> ari-tczew: i'm the upstream for byobu, and an Ubuntu developer;  i generally release byobu upstream, and upload to Ubuntu at the same time
[16:38] <kirkland> ari-tczew: i'd like to be a Debian maintainer of the package, and upload to Debian too, simultaneously
[16:38] <kirkland> ari-tczew: i need to jump through the DM hoops, though, and i haven't gotten around to that
[16:42] <ari-tczew> kirkland: http://packages.qa.debian.org/b/byobu.html shows: maint    Dustin Kirkland
[16:43] <kirkland> ari-tczew: i saw that and asked;  it just means that i have had uploads sponsored
[16:43] <kirkland> ari-tczew: if you fancy sponsoring my packages, i would be glad
[16:43] <ari-tczew> kirkland: hehe, I'm not Debian Developer
[16:43] <kirkland> ari-tczew: okay
[16:44] <kirkland> ari-tczew: so what exactly are you trying to accomplish?
[16:44] <kirkland> ari-tczew: you want byobu uploaded to ubuntu and debian at the same time, right at release?
[16:44] <ari-tczew> kirkland: yea, I'd be glad to see packages Ubuntu = Debian (synced)
[16:45] <kirkland> ari-tczew: even if that means that debian is a downstream of ubuntu in this case (as long as they're in sync)?
[16:45] <Laney> you can infact upload the same exact package simultaneously
[16:45] <Laney> using syncpackage
[16:47] <kirkland> Laney: i assume that requires DD or DM privs?
[17:01] <ziggystar> I'm fighting with a bug with nm-applet. For a second user it seems it's lacking permissions. Running it with sudo works fine for that user. Can someone tell me how nm-applet gets started by gnome?
[17:07] <james_w> cnd: fixed
[17:07] <cnd> james_w: awesome!
[17:07] <cnd> thanks!
[17:40] <mathiaz> pitti: hi!
[17:41] <mathiaz> pitti: re landscape-client SRU - there are two of them in the queue for now
[17:41] <mathiaz> pitti: what should we do with them?
[17:41] <mathiaz> pitti: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
[17:43] <shadeslayer> hey! any desktopcouch maintainers around?
[17:53] <Laney> kirkland: Right, I'm thinking that you build your package for unstable and then syncpackage gives you a changesfile for M or whatever
[17:53] <kirkland> Laney: what provides syncpackage?
[17:53] <Laney> FWIW getting DM for your package should be easy
[17:53] <Laney> ubuntu-dev-tools
[17:55] <cr3> in general, if a storage device fails to automount, against which package should the bug be reported?
[17:56] <cr3> if gvfsd, what would be the corresponding package on kubuntu?
[17:56] <cjwatson> use 'ubuntu-bug storage', I believe
[17:57] <cjwatson> which works it out
[17:57] <cjwatson> (it uses gvfs on GNOME and kdelibs5 on KDE, but it's still best to go through the automatic thing)
[17:58] <cr3> cjwatson: thanks for reminding me about that :)
[17:58] <Laney> ah, yes I have one of those bugs to file
[18:42] <ccheney> is there  a way to disable ipv6 in maverick?
[18:42] <ccheney> i'm testing some code and i think its having issues on using ipv6
[18:45] <ccheney> ah i finally found out the correct syntax
[18:57] <lex79> cjwatson: I can't upload kdebase-workspace, meta-kde and pkg-kde-tools, are not in the set of packages for a kubuntu-developer. Is it possible fix that? :)
[19:13] <cr3> anyone know about a firewire device which seems to have started appearing with vendor id 0xd00d1e (looks suspicious, "doodle")
[19:14] <cr3> hm, seems to come up as: FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04). weird how the vendor id detected > 0xFFFF
[19:16] <cr3> the weird thing is that /sys//devices/pci0000:00/0000:00:1e.0/0000:05:0b.1/fw0/vendor is returning the id 0xd00d1e whereas lspci is returning another vendor id
[19:16] <shadeslayer> hi,can someone look at https://bugs.launchpad.net/ubuntu/+source/desktopcouch/+bug/565376
[19:16] <shadeslayer> seems ubuntu dev is the maintainer of the package
[19:16] <shadeslayer> and it needs a SRU
[19:19]  * shadeslayer knows no Ubuntu Devs
[19:21] <arand> shadeslayer: Go through the !sru process, and wait patiently. Is the normal procedure in those cases.
[19:22] <shadeslayer> arand: have gone through it
[19:22] <shadeslayer> arand: ive attached a debdiff to the package
[19:22] <shadeslayer> uh... s/package/bug report
[19:22] <shadeslayer> just needs some love :)
[19:24] <arand> shadeslayer: Is it fixed in maverick?
[19:24] <shadeslayer> arand: no,should i attach a debdiff for it too?
[19:24] <shadeslayer> needs the same change to maverick too...
[19:24] <arand> shadeslayer: https://wiki.ubuntu.com/StableReleaseUpdates : 1. Check that the bug is fixed in the current development release, and that its bug report task is "Fix released". It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch. ...
[19:24] <shadeslayer> arand: basically.. gnome keyring needs to be installed along with python-desktopcouch for the gui authentication stuff
[19:25] <shadeslayer> arand: oh my..
[19:25] <shadeslayer> arand: will post a debdiff for maverick,will you look into it?
[19:26] <arand> shadeslayer: I'm no dev either, so I'm afraid no.
[19:26] <shadeslayer> arand: i actually posted the kubuntu devs the debdiff for maverick,but they told me to poke package maintainers
[19:26] <shadeslayer> arand: no problem :)
[19:26] <cr3> cyphermox: when you have a moment, please confirm bug #601161. thanks!
[19:27] <arand> shadeslayer: Also, for SRU there is some formatting of the bug report to be done as well (test case, etc.), but that's all mentioned in the process which you've already read ;þ
[19:29] <arand> shadeslayer: If you don't have upload right you basically stop halfway at step 3. nominating it.
[19:30] <shadeslayer> arand: got it
[19:31] <shadeslayer> arand: anyways need to get it fixed in maverick first :P
[20:10] <njin> Someone remember if past years was possible to have SO on one disk and swap on another ?
[20:27] <directhex> SO?
[22:05] <jono> TheMuso, ping?
[22:41] <shadeslayer> any idea where apturl stores its desktop file?
[22:44] <micahg> shadeslayer: it doesn't have one
[22:45] <shadeslayer> micahg: really?
[22:45] <shadeslayer> i thought i saw one
[22:45]  * micahg doesn't see one in the file list
[22:45] <shadeslayer> micahg: what about apturl-kde ? or apturl-common?
[22:46] <shadeslayer> hmm.. your right
[22:48] <cjwatson> lex79: fixed
[23:10] <directhex> oh yes, the NEW queue. i forgot about that thing
[23:43] <lex79> cjwatson: thanks :)