[00:00] <james_w> the LOSAs have permissions to control IIRC
[00:00] <james_w> knowing what to do is a little more tricky :-)
[00:00] <lifeless> spm: could you start glib2.0 off please ;)
[00:00]  * lifeless finds out by experiment
[00:01] <spm> james_w: any docco you can point me at? :-)
[00:01] <james_w> spm: I can do it
[00:02] <james_w> done
[00:02] <spm> ta muchly - if you can just dump a copy of your commands used to<EMAIL_ADDRESS>I'll add to our wiki.
[00:03] <lifeless> thanks james_w
[02:29] <lamont> so... how do I get sound back on this computer now that it's running karmic?
[02:29] <ebroder> lamont: You ask in #ubuntu
[02:30] <lamont> meh
[02:30] <ebroder> Sorry - it's an impulse these days
[02:30] <ebroder> I don't actually know
[02:32] <lamont> I'm guessing it has something to do with pulseaudio not showing any hardware, while lspci shows an Intel 82801JI providing the Audio controller...  but enough for tonight
[02:33] <stgraber> lamont: might be an issue with pulseaudio's udev plugin
[02:33] <lifeless> lamont: hi
[02:34] <lifeless> lamont: several things:
[02:34] <lifeless> lamont: check you have an up to date kernel.
[02:34] <lifeless> lamont: check that the sound isn't simply muted
[02:34] <lifeless> lamont: and something hda related I don't really know about
[02:36] <lamont> lifeless: fresh upgrade on the machine to karmic+security+updates
[02:36] <ajmitch> there's also a useful linux-backports-modules-alsa-karmic-generic package if it's really recent hardware
[02:37] <lamont> ajmitch: ISTR buying it about 6-7 months ago... kinda ancient by most standards
[02:37] <lamont> lifeless: the sound prefs menu shows no hardware - I'm guessing that it has something to do with udev etc
[02:37] <ajmitch> even if it's not recent & buggy like mine, there may be driver fixes in there if it's not something as simple as being muted in the wrong place
[02:39] <lamont> well, cat /vmlinuz > /dev/dsp does generate some sound-like stuff in the speakers...
[02:39] <lamont> so I suspect the kernel will talk to it
[02:39] <lifeless> lamont: what kernel version do you have?
[02:39] <lifeless> specifically, uname -a
[02:40] <lamont> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
[02:40] <lifeless> so
[02:40] <lamont> so WTF am I running a jaunty kernel?
[02:40] <lifeless> please try to figure that out
[02:40] <lifeless> a number of folk have had this happen
[02:40] <ajmitch> there was a bug about grub not being updated, iirc
[02:40] <lifeless> my cause was a missing hook in kernel-img.conf
[02:41] <lifeless> what does grep hook /etc/kernel-img.conf show?
[02:41] <lamont> do_symlinks = yes
[02:41] <lamont> relative_links = yes
[02:41] <lamont> do_bootloader = no
[02:41] <lamont> do_bootfloppy = no
[02:41] <lamont> do_initrd = yes
[02:41] <lamont> link_in_boot = no
[02:41] <lifeless> slangasek: ^ same symptoms I have.
[02:41] <lamont> and update-grub seems to correct menu.lst.  rebooting now.
[02:42] <ajmitch> I know I changed kernel-img.conf manually some time ago, perhaps this only affects people who've upgraded through a few releases?
[02:42] <lifeless> lamont: please add any data you can gather to  https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/470265
[02:42] <lifeless> lamont: you want to add these to your kernel-img.conf too:
[02:42] <lifeless> postinst_hook = update-grub
[02:42] <lifeless> postrm_hook   = update-grub
[02:57] <lifeless> james_w: any reason we can't just upgrade the branch?
[03:00] <james_w> lifeless: because the upgrade guide tells me not to?
[03:04] <lamont> lifeless: the karmic kernel has the amusing(?) feature of not having a working network.  OTOH, after rebooting into the jaunty kernel, bip won't connect
[03:07] <lamont> heh
[03:17] <lifeless> james_w: the guide is overly cautious
[03:17] <lifeless> james_w: bzr-builder and builddeb are very small communities
[03:17] <RAOF> There isn't an update-manager script for lucid yet, is there?
[03:20] <StevenK> RAOF: Not that I recall
[03:22] <RAOF> Curses.  I seem to have killed the rtc backup battery on this laptop.
[03:24] <lifeless> Laney: https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/470265 <-
[03:24] <lifeless> bah
[03:24] <lifeless> Laney: sorry
[03:35] <lamont> _there_.
[03:35] <stgraber> lamont: On which kernel ?
[03:36] <lifeless> lamont: https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/470265 <-
[03:37] <lamont> karmic kernel, adding a pre-up in interfaces to bring up the physical dev beneath the bridge so I can have networking (jaunty did OK without that), and for bonus, I get sound again
[03:37] <lamont> well, after nuking network mangler with prejudice
[03:37] <lamont> it very politely generated an empty resolv.conf
[03:37] <lamont> for values of "empty" == just the comment that NM created it
[03:43] <lifeless> lamont: have a look at that bug if you would, as your surface symptoms are identical and we need to figure out why the hooks are not present
[03:44] <lamont> well.. the machine started life as hardy, and has dist-upgraded from there
[03:44]  * lamont looks at the bug
[03:44] <lifeless> lamont: thats good to know, mine was a fresh install of jaunty
[03:45] <lamont> -rw-r--r-- 1 root root 184 2009-02-10 01:02 /etc/kernel-img.conf
[03:45] <lamont> totally recent
[03:45] <lamont> :-(
[03:46] <lamont> interesting.
[03:47] <lamont> feb 21 was when I flattened the box and rebuilt it as an amd64 box instead of an i386 box.  In the course of that, my diff has:
[03:47] <lamont>  link_in_boot = no
[03:47] <lamont> -postinst_hook = update-grub
[03:47] <lamont> -postrm_hook   = update-grub
[04:01] <slangasek> lifeless: right, so what do you and lamont have in common when you're installing, that no one else does? :)
[04:01] <lifeless> slangasek: we're DD's?
[04:02] <lifeless> lamont: how did you do the rebuild?
[04:02] <slangasek> siretart: libbar's soname doesn't need to be bumped in the /general/ case, but versioned symbols are pretty important for avoiding segfaults there
[04:03] <lamont> it's an ugly raid 6 box - pretty sure I alternate-installed onto a new partition on the lvm mess
[04:04] <lamont> slangasek: it was nothing like the crossgrade I did on my laptop.  honest.
[04:27] <ebroder> Can I actually tell them to leave the AP unplugged?
[04:28] <ebroder> Whoops! Wrong window :)
[04:38] <slangasek> lamont: do you have a /var/log/installer?
[05:05] <lamont> slangasek: I'll dig for it in a moment
[05:08] <lamont> slangasek: it even has a right-sounding date
[05:27] <stephenahpohliss> hellp
[05:27] <stephenahpohliss> *hello
[05:32] <stephenahpohliss> developer?
[06:04] <slangasek> lamont: post it to bug #470265?
[06:11] <lamont> slangasek: meh.  will do so in the morning when I can think again
[06:11]  * lamont -> bed
[07:02] <George_E> Is there an easy way to take the output of ldd and determine package dependencies?
[07:04] <RAOF> George_E: Reasonably so, yes.  dpkg-shlibdeps does something pretty much like that.  What are you aiming for, though?
[07:06] <George_E> Just to create a DEB file with proper dependency info.
[07:06] <RAOF> Oh.  Then call dh_shlibdeps, and it'll be done automatically.
[07:06] <George_E> Just to create a DEB file with proper dependency info.
[07:06] <RAOF> We don't manually work out package runtime dependencies ourselves, generally :)
[07:07] <Chipzz> George_E: 08:06 < RAOF> Oh.  Then call dh_shlibdeps, and it'll be done automatically.
[07:07] <George_E> Oh good. I was worried Id have to manually do it.
[07:07] <RAOF> Well, not entirely automatically, I guess.  You'll need ${shlibs:Depends} in your Depends: field, but that'll be filled in automatically.
[07:08] <George_E> Thanks.
[07:59] <dholbach> good morning
[08:17] <siretart`> slangasek: unfortunately in my case, upstream doesn't use symbol versioning. :(
[08:17] <siretart`> morning folks!
[08:17] <Tm_T> good morning
[08:38] <\sh> moins
[08:38] <pitti> Good morning
[08:48] <Dajago> Can someone help me in the direction of debugging/fixing certain issues with Ubuntu (Gnome and others)? What I need, what the best tools are, etc?
[08:58] <siretart`> has mass-autosyncing from debian/testing started yet?
[08:59] <\sh> siretart, I wonder if deb source format 3 is already supported on LP
[08:59] <siretart`> \sh: it isn't
[09:18] <pitti> \sh: should be supported in the LP December 11th rollout, AFAIR
[09:18] <pitti> siretart`: yes, autosyncs were already started
[09:19] <siretart`> pitti: is it just me or do we have considerably less syncs than in karmic up to now?
[09:19] <pitti> may be; I didn't follow them really
[09:32] <seb128> siretart`, syncs are done on testing it changes less quickly
[10:21] <Keybuk> pitti: did the -proposed kernel make it to -updates yet?
[10:25] <pitti> Keybuk: just copied over
[10:26] <Keybuk> yay
[10:30] <\sh> Keybuk, did you find the time to check bug #446031 ? it would be really important to get that fixed and provide a update for karmic
[10:31] <Keybuk> \sh: there was this little thing called "UDS" last week
[10:34] <\sh> Keybuk, I know I know, was wondering if nobody was discussing those upstart issues @UDS with you? :) anyways..there are more problems with the handling of /e/n/i inside upstart...
[10:34] <Keybuk> \sh: there was an entire session on such issues?
[10:35] <Keybuk> did you not remotely participate in it, if it interested you so much?
[10:35] <\sh> Keybuk, dunno..didn't have the time to follow UDS at all...timezone and work related issues :(
[10:38] <\sh> Keybuk, i think you mean https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-upstart-server-review
[10:38] <Keybuk> \sh: that's the one
[10:39] <\sh> Keybuk, any notes on this...I would like to take a look on it :)
[10:39] <Keybuk> \sh: the notes will be at that URL, or on gobby
[10:39] <\sh> Keybuk, url not set...let's see on gobby
[10:40] <soren> They're on gobby.
[10:40] <soren> Name matches blueprint name.
[10:40] <\sh> soren, thx :)
[10:45] <\sh> soren, do we have somehow an overview of how many people are affected by this bonding problem? if the fix of mkdir -p /var/run/network helps most of them, I would like to create an update for karmic...(just forgetting people with hotplug interfaces, who are not catched by this effectively)
[10:46] <soren> Absolutely no clue.
[10:50] <Keybuk> \sh: there's no fix in lucid to backport to updates yet
[10:51] <\sh> Keybuk, right, that's why there's a debdiff for lucid on bug #446031 and ubuntu main sponsors subscribed ;)
[10:53] <\sh> Keybuk, but really it's just only a workaround which helps right now for people like me or other server people, for a really serious problem (which does affect not only server people but also desktop/laptop people)
[11:01] <Keybuk> \sh: what's the not-a-workaround?
[11:03] <\sh> Keybuk, not-a-workaround? hmm? elaborate pls :)
[11:06] <Keybuk> \sh: you said it's only a workaround
[11:06] <Keybuk> I'm obviously more interested in the fix that's not just a workaround
[11:06] <Keybuk> what is it?
[11:08] <\sh> Keybuk, you tell me ;) soren and I tried many possibilities which were not helping...so regarding this, the attached /etc/init/networking.conf patch in ifupdown package is the only way to go for a working bonding setup (on servers where this setup is used), it could help people now for karmic
[11:08] <Keybuk> \sh: in other words, we don't fully understand this problem
[11:09] <Keybuk> in which case rushing a "workaround" into a *stable* release is a very bad thing to do
[11:23] <\sh> Keybuk, I don't fully understand how upstart works in this case, that's right, but I do understand that there is a timing problem between /etc/init/network-interface.conf and /etc/init/networking.conf triggers and that creating the directory for ifup helps here, because for the bonding driver it's not necessary that the hw nics are already initialized, but it needs to know which hw nics it should use, and that doesn't really work right now, because
[11:23] <\sh>  of the missing directory (ifup -a fails when /var/run/network/ is not available)
[11:25] <\sh> Keybuk, I tested the change on 10 servers and it helped to boot into a usable server environment so I think this "workaround" is a good solution for now, to make the upgrade from releases < karmic work
[11:28] <\sh> Keybuk, and I'm happy to help to find a better solution for lucid, if there is any in the small timeframe we have until lucids release :)
[11:29] <Keybuk> \sh: have you tested it on any machines which didn't have the original bug?
[11:29] <Keybuk> can you safely say that there aren't *other* bugs that won't be introduced by this change?
[11:30] <\sh> Keybuk, I tested the patched package on my laptop (which has -desktop flavour) and didn't see anything which fails
[11:31] <Keybuk> so no, you haven't tested it then
[11:31] <Keybuk> seriously
[11:31] <\sh> Keybuk, Lars W. tested it with his setup (original bug) this works, too, has he wrote in his comment
[11:31] <\sh> s/has/as/
[11:31] <Keybuk> it's better to have a known bug that bonded interfaces don't work
[11:31] <Keybuk> than to introduce unknown bugs
[11:33] <\sh> Keybuk, well, how would you test it better then that? mkdir -p /var/run/network in /etc/init/networking.conf is not much different from the mkdir -p /var/run/network in /etc/init/network-interface.conf
[11:33] <\sh> Keybuk, and to know that the networking.conf service is triggered earlier then network-interface.conf (whysoever)
[11:33] <Keybuk> \sh: exactly, and by fixing this bug, you introduce an untested condition where two ifup's for the same device may be happening at the same time
[11:34] <Keybuk> if networking is honestly being started before network-interface for lo
[11:34] <Keybuk> then you introduce a new condition where "ifup lo" (from ifup -a) happens *before* network-interface lo
[11:34] <Keybuk> which could cause a whole new set of bugs
[11:36] <\sh> Keybuk, ok...regarding the special case of "lo", do you think it's better to introduce an network-interface-lo.conf, which only calls "ifup lo", before network-interfaces.conf and/or networking.conf? (i mean if we are on this track, we could as well fix ntp to be restarted everytime ifup is called ;))
[11:36] <Keybuk> no, I don't think that's better
[11:36] <Keybuk> furthermore
[11:36] <Keybuk> networking.conf has "stopped udevtrigger" in its start condition
[11:36] <Keybuk> this should mean that lo has already been created
[11:36] <Keybuk> (but isn't due to upstart not getting there yet)
[11:37] <Keybuk> maybe "and net-device-up IFACE=lo" is also needed in networking.conf, instead of that mkdir
[11:37] <Keybuk> there's a whole lot of "ifs" and "maybes" here
[11:37] <Keybuk> there should be an automatic SRU rejection for any "if" and "maybe"
[11:38] <\sh> Keybuk, that's why I don't do "SRU"s ;)
[11:39] <\sh> Keybuk, which service should emit "net-device-up" right now if not udev?
[11:39] <Keybuk> our situation, right now, is that there is a known bug in karmic
[11:39] <Keybuk> and that there's a workaround on the bug report that many people claim fixes it for them
[11:39] <Keybuk> but that workaround may introduce additional problems for people who aren't
[11:39] <Keybuk> the prudent course of action here is to release note the known bug
[11:40] <Keybuk> refer people to the bug report (with the workaround)
[11:40] <Keybuk> while the problem is studied in lucid, and fixed in lucid properly
[11:40] <Keybuk> (which may not be suitable for SRU)
[11:40] <\sh> Keybuk, wasn't that the reason to introduce "-proposed" to check that an update doesn't harm anyone?
[11:40] <Keybuk> no
[11:43] <\sh> Keybuk, then I don't understand -proposed at all...
[11:45] <ion> The addition of -proposed shouldn’t change the acceptable basis for SRUs at all. It’s just a safety buffer for what are thought to be safe for -updates in the first place. Or i could be wrong. :-)
[11:48] <\sh> reading https://wiki.ubuntu.com/Testing/EnableProposed it should be a way to test if a serious regression is fixed with a -proposed update (which will eventually become an SRU)...but that's me...the other way is to test dist-upgrades with a tweaked d-i installer preseed where a PPA is enabled...
[11:51] <sebner> huhu \sh :D
[11:51] <\sh> gugucks sebner
[13:54] <seb128> does anybody plan to run an autosync today?
[13:56] <geser> seb128: do you know when were new packages (missing in Ubuntu) synced from Debian testing the last time?
[13:56] <seb128> do we still have issues due to the new source format and soyuz?
[13:56] <seb128> geser, no
[13:56] <seb128> I expect archive admin activy has been somewhat low due to uds
[13:56] <geser> I guess that too when looking at the NEW queue
[13:59] <seb128> ok, slangasek is on holidays apparently
[14:00] <seb128> pitti, ^ do you know about syncs?
[14:06] <ebroder> Oh, wait, I guess not actually. Never mind
[14:06] <ebroder> Wrong window again, sorry
[14:22] <pitti> seb128: they can happen, you just have to blacklist 3.0 format packages (sync will fail on them)
[14:23] <seb128> ok thanks
[14:23] <seb128> pitti, no objection to me running an autosync run?
[14:23] <pitti> seb128: no, please go ahead
[14:23] <seb128> ok
[14:23] <seb128> thanks
[15:16] <gwadeloop> Hello good morning
[15:16] <gwadeloop> since this morning I can only boot in "gnome failsafe" mode
[15:17] <gwadeloop> the nividia driver is not working anymore as well as the broadcom proprietary driver
[15:18] <gwadeloop> I am using an HP dv6 laptop
[15:19] <seb128> what version of ubuntu do you use?
[15:19] <gwadeloop> is there any reason that would explain this situation?
[15:19] <seb128> what did you upgrade before rebooting?
[15:19] <gwadeloop> seb128: I am using 9.10
[15:19] <Keybuk> funnily enough, the nvidia driver didn't work for me this morning either
[15:20] <Keybuk> (on 9.10)
[15:20] <gwadeloop> and I did  update/upgrade before rebooting
[15:20] <gwadeloop> Keybuk: this is not really funny :-(
[15:20] <gwadeloop> Keybuk: but I am glad to not be the only one
[15:20] <Keybuk> the primary difference, I suspect, being that I didn't upgrade anything
[15:21] <Keybuk> it works if I don't boot with "splash" on the kernel command-line, maybe try that?
[15:22] <gwadeloop> Keybuk: you mean startx ?
[15:22] <Keybuk> no
[15:35] <amgarching> Hi, will dd if=/dev/zero of=/root/BIGFILE actualy fill the disk with zeros on ext4? Need it for compression of images.
[15:39] <zul> dholbach: how do you unsubscribe main-sponsors from the bug?
[15:40] <dholbach> zul: you need to be member of the team
[15:40] <zul> dholbach: i thought i was a member of the team
[15:40] <dholbach> added you
[15:40] <zul> thanks
[15:40] <dholbach> reload the bug :)
[15:41]  * nixternal hugs dholbach
[15:43]  * dholbach hugs nixternal back
[15:47]  * fagan did enough hugging of dholbach
[15:47]  * dholbach hugs fagan some more :)
[15:47] <fagan> :)
[15:48] <blackxored> hello, I have always used sbuild with an apt-cacher-ng setup but now since I upgraded to 64 bits I'm recreating them, and passing --debootstrap-mirror to the mk-sbuild-lvm script fails to get the Release file, any clues?
[15:48] <maco> fagan: so you made it to the plane, then? laura was flippin out, thinking youd gone back to sleep and were gonna miss it
[15:49] <fagan> maco: I did something dumb there
[15:50] <fagan> I did a quick scan for laura and then got in the first taxi because I thought she went off without me
[15:50] <fagan> she was angry
[15:50] <blackxored> anyone?
[16:16] <primes2h> apw: Hello, could you please have a look at bug #441835? There are still issues with floppy (seems that a brand new one come up every release unfortunately :( ). There are enough info attached (even on duplicate bugs) and I'm investigating on other bug reports that are probably duplicate as well.
[16:16]  * apw sends a usb stick to everyone
[16:18] <apw> primes2h, do you have this issue?
[16:19]  * fagan hasnt seen a floppy in 7 years
[16:21]  * apw pokes primes2h
[16:21] <apw> fagan, not sure i own any machines even having a controller let alone a drive ...
[16:22] <primes2h> apw: Yes, in a few pc that have floppy device, and I have friends that have it as well, unfortunately floppy is still quite common here in Italy and in other country, especially on desktop pc.
[16:22] <primes2h> countries
[16:23] <primes2h> apw: people complains a lot on bug reports too
[16:24] <primes2h> apw: They have old data or other stuff still on floppy. It's hard to believe but it's true.
[16:26] <primes2h> This is true especially in poor countries where there are old pcs still with floppy
[16:28] <apw> primes2h, yeah i am sure there are a lot about
[16:28] <apw> in the bug report it talks about being able to just use the device using moutn?
[16:28] <apw> can you confirm that behaviour
[16:32] <primes2h> apw: sorry, I was on the phone
[16:32] <primes2h> apw: yes, I confirm it
[16:32] <primes2h> apw: I can mount it via terminal
[16:33] <primes2h> apw: mount /dev/fd0 /media/floppy0 etc.
[16:33] <primes2h> sudo
[16:36] <apw> primes2h, ok so that is not a kernel issue i shouldn't think
[16:36] <primes2h> apw: but it creates another icon on Places->
[16:37] <apw> as you have a /dev/fd0 to mount from
[16:37] <primes2h> apw: different from Places->Floppy Device
[16:37] <apw> the kernel has done its bit, as has udev as you have a /dev/fd0 in the first place
[16:37] <apw> and as it works, that also sounds liek the kernel did the right thing
[16:37] <apw> so i would assume its gvfs or similar which is unhappy
[16:38] <apw> primes2h, can you unmount the mount you did by hand and try
[16:38] <apw> gfvs-mount -d /dev/fd0
[16:38] <apw> and tell me what happens
[16:41] <primes2h> apw: as a user, it tells me "no volume for device file /dev/fd0"
[16:42] <primes2h> apw: as root (sudo) it mounts the floppy as mount did
[16:42] <primes2h> apw: still creating another icon
[16:42] <primes2h> apw: with some errors. on the terminal
[16:43] <primes2h> apw: but floppy is mounted and I can browse it
[16:45] <JanC> sounds like a problem with permissions then?
[16:45] <primes2h> JanC: Seems to be
[16:45] <apw> perhaps so
[16:46] <apw> primes2h, ok could you attach the dmesg output and the logs from udev (/var/log/udev) and the output you see from testing gvfs-mount as  yourself and as sudo
[16:50] <apw> primes2h, oh and an ls -l /dev/fd0 as well
[16:54] <primes2h> apw: Ok.
[17:01] <dpm> pitti, hey, I
[17:01] <dpm> I've got a question on langpacks on the livecd
[17:02] <dpm> for the languages with language packs on the ISO
[17:02] <dpm> are the full translations (the PO files) included?
[17:15] <pitti> dpm: yes, that's what the langpacks are about
[17:15] <pitti> dpm: well, the .mo files of course, not the .po files
[17:16] <primes2h> apw: done. Thank you very much. :)
[17:17] <dpm> pitti, thanks, that's what I thought (and I meant mo files, as you correctly point out), I was just wondering if those few langpacks were put fully on the CD.
[17:18] <dpm> anyway, did you have a good trip back?
[17:22] <pitti> dpm: yes, went fine; how about you?
[17:46] <dpm> pitti, oh, fine as well. happy that I didn't get any jet lag on the way back :)
[20:45] <micahg> so there are 5 versions of python now?
[20:46] <ebroder> Apparently
[21:32] <mneptok> http://theoatmeal.com/comics/pony
[21:32] <mneptok> go forth, Ubuntu developers, and ride for Lucid.
[21:41] <ajmitch> mneptok: that page is suitably odd to be recommended by you
[22:26] <hedkandi> how do you link against a shared object at build time?
[22:48] <mneptok> ajmitch: i love you, too. :)
[22:48] <ajmitch> aw thanks :)
[23:00] <bdrung> seb128: refering to bug #482886. the debian maintainer did not want to make the test suite failing.
[23:01] <seb128> bdrung, is slomo the debian maintainer?
[23:01] <bdrung> seb128: he is one of them
[23:02] <seb128> bdrung, who did you talk to?
[23:02] <seb128> ie who said no?
[23:02] <seb128> I will talk to slomo when he's around
[23:02]  * bdrung searches the mail
[23:03] <bdrung> seb128: i only wrote to their mailing list.
[23:03] <bdrung> seb128: the response: "Why? Could you file a bug for this with some explanations why you need this?"
[23:04] <seb128> ok
[23:04] <seb128> I will talk to slomo tomorrow
[23:04] <seb128> the rational is that testsuites are good to avoid breakage in stable updates for example
[23:50] <ari-tczew> seb128, thanks for syncs!
[23:51] <seb128> ari-tczew, you're welcome


[00:07] <allquixotic> Hi, I am trying to add a patch to the quilt stack in lp:~ubuntu-desktop/rhythmbox/ubuntu. I used `quilt import' to pull the patch in. but lintian gives me this error: "E: rhythmbox source: quilt-series-references-non-existent-patch 01_vala_vapigen.patch" The problem is that exact file *does* exist in the patches dir, and it's in the right place in the series file. What gives?
[00:07] <slangasek> allquixotic: did you 'bzr add' the patch file?
[00:08] <allquixotic> slangasek: No :) That's all I had to do?! OK. Let me try that.
[00:09] <slangasek> allquixotic: without 'bzr add', the new patch file isn't part of the bzr branch and won't be picked up by bzr bd
[00:09] <allquixotic> slangasek: Ah, right. And I was running bzr-buildpackage which == bzr bd. Many thanks!
[00:09] <slangasek> sure :)
[00:10] <RAOF> What sort of useless filesystem debugging tool segfaults when fed a broken filesystem?  GAH!
[00:12] <corecode> is there a special tool to write to debian/changelog and commit a bzr revision at the same time?
[00:14] <TheMuso> corecode: debcommit
[00:14] <TheMuso> corecode: sorry, you have to write to debian/changelog first with debcommit
[00:15] <TheMuso> slightly misread your question.
[00:20] <corecode> ok
[00:20] <corecode> thanks
[00:32] <slangasek> so, 'dch && debcommit' :)
[00:35] <slangasek> ttx: commented the bug
[01:00] <smoser> anyone able to tell me why there would be no maverick build of libjibx-java ?
[01:00] <smoser> https://launchpad.net/ubuntu/+source/libjibx-java
[01:01] <smoser> i'm guessing ftbfs ?
[01:01] <ajmitch> smoser: it was removed, see https://edge.launchpad.net/ubuntu/+source/libjibx-java/+publishinghistory
[01:05] <smoser> hm...
[01:05] <smoser> so it *does* have reverse depends in ubuntu
[01:08] <slangasek> smoser: check with Riddell, I guess?  Generally we shouldn't auto-process removals from Debian for packages that have reverse dependencies in the archive still
[01:09] <slangasek> smoser: would bringing the new libjibx1.{1,2}-java packages into maverick address the issue?
[01:09] <smoser> i dont know the answer to that.
[01:47] <mathiaz> kees: hi!
[01:48] <mathiaz> kees: could you do a search on the archive to see if there are any package using dbi_conn_error_flag?
[01:48] <mathiaz> kees: this function has been changed in the new upstream version of libdbi
[02:08] <mathiaz> kees: nevermind - I've been able to get what I was looking for
[03:28] <allquixotic> When I grab a source package via `apt-get source' and the sources dir contains debian/patches/nn_*.patch and debian/patches/series, how do I apply those patches? quilt?
[03:52] <smoser> kees, around ?
[03:53] <smoser> euca_rootwrap question.
[04:31] <kees> smoser: email me; i'mhigh latency this week (at blackhat and defcon conferences)
[04:32] <smoser> i found the answer.
[04:32] <smoser> whether ror not you'd like it to be true, a program invoked via euca_rootwrap can fork/exec anything it wants.
[04:32] <smoser> i had thought that your security measures might have stopped that.
[04:55] <kees> smoser: ew, it's not supposed to be able to do that
[04:55] <smoser> hm..
[04:55] <smoser> maybe i did something wrong
[04:56] <kees> maybe you're using the upstream version instead of the replacement i wrote?
[04:58] <smoser> i dont think so
[04:59] <smoser> from our packages:
[05:00] <smoser> kees, http://paste.ubuntu.com/470524/
[05:00] <smoser> maybe i wasn't explaining myself well.
[06:44] <pitti> Good morning
[06:44] <ion> ing
[06:46] <andreserl> Hi all. Have a quick question. Should we Build-Depend in a virtual package, or in a real package?
[06:55] <pitti> zul: can you please aply v7x' debdiffs in bug 611101  and bug 611102 and then actually test the package?
[07:04] <kees> smoser: uhm... you added /bin/sh to the conf...
[07:04] <smoser> yes.
[07:04] <smoser> and then invoked /bin/sh (a command in the conf)
[07:04] <kees> so, of course it can run anything.
[07:04] <smoser> and it forked something else
[07:04] <smoser> thats what i was asking.
[07:04] <smoser> if you were intending to stop forks of other programs.
[07:05] <kees> no, and that would probably break other stuff.
[07:05] <smoser> right
[07:05] <smoser> ok.
[07:05] <kees> the euca white list was built to just try to not make it blindingly simple to gain root privs from the euca user
[07:06] <kees> it's almost certainly possible, but it was REALLY possible with the old one, which just did exec(argv[1]) etc...
[07:06] <kees> the idea was to try to help euca start to build up a whitelist and helpers to validate arguments, etc.
[07:07] <kees> but since it's still not upstream, I don't think there are any plans to improve it.
[08:08] <dholbach> good morning
[08:17] <diwic> dholbach, good morning
[08:17] <dholbach> hey diwic
[08:37] <mdz> mvo, unfortunately I can no longer test that nvidia progress bar issue. the nvidia card in question is dead (its fan stopped)
[08:38] <mvo> mdz: thanks, I can reliable reproduce it now on both a ati and a nvidia card, looks like a issue with cairo 1.9.x hitting slow rending path(es) on these cards
[08:38] <mvo> mdz: its now in bug #595845 (including small demp and timing info)
[08:56] <RAOF> I'm not entirely sure where that slowness is coming from - I was going to look at oprofile output, but on my nouveau system the slowness *isn't* accompanied by CPU usage, so oprofile wasn't catching any hot paths.
[09:02] <mvo> RAOF: today my nouveau system does not start (complains that drm can not set DRM device bus id, otherwise I would be able to help
[09:03] <RAOF> Gargh.
[09:03] <RAOF> Yeah, that's a race condition.
[09:03] <RAOF> Delete the ureadahead pack file and your boot should slow down enough for X to start
[09:04] <RAOF> Alternatively, add drm to your initramfs by setting FRAMEBUFFER=y in one of the conf files.
[09:06] <RAOF> mvo: bug #606244 is what you want to follow for that.
[09:08] <mvo> RAOF: thanks!
[09:46] <pitti> 2010-07-29 08:46:34 INFO    Comment: NBS
[09:46] <pitti> 2010-07-29 08:46:34 INFO    1196 packages successfully removed.
[09:46] <pitti> wow
[09:46] <pitti> seems nobody did that for a while
[09:48]  * pitti removes 543 more old kernel packages
[12:21] <apw> pitti, ! 543 ! ... that really hasn't been done for a while
[12:23] <chrisccoulson> pitti - how frozen is lucid for SRU's?
[12:23] <chrisccoulson> i have an ubufox SRU with a couple of fixes in (one of them disables the "Report a problem" menu item in firefox)
[13:01] <pitti> chrisccoulson: once mysql lands (hopefully today, will coordinate with zul), then that's "it"
[13:22] <Riddell> TheMuso: ping?
[13:55] <TheMuso> Riddell: pong
[13:57] <Riddell> TheMuso: I e-mailed, you should be asleep :)
[13:57] <TheMuso> Riddell: heh, its about 11:0PM in the evening, will take a quick peak before heading to bed. :)
[13:59] <TheMuso> Riddell: speech-dispatcher. I have resigned from the fork, and don't intend to package opentts for maverick.
[14:01] <TheMuso> Now I am off to bed.
[14:49] <ikonia> dholbach: are you there ?
[14:51] <dholbach> ikonia: yes
[14:51] <ikonia> dholbach: can I nudge you a pm please ?
[14:51] <dholbach> you can try :)
[15:32] <mathiaz> superm1: hi - I'm currently investigating bug 598030
[15:32] <mathiaz> superm1: is there anything in the code that would make things harder?
[15:33] <mathiaz> superm1: is inventory_firmware_gui the only bit that call anything gui related?
[15:42] <quadrispro> ehy mvo, nice to see you aroun! I've mail'd you but now I have to leave, see you later
[15:54] <superm1> mathiaz, you are best speaking with michael brown about that stuff, but i dont see him on right now
[15:54] <superm1> mebrown is his handle
[15:58] <mathiaz> superm1: great - thanks
[16:01] <superm1> mathiaz, here's mebrown
[16:01] <superm1> you can restate your question to him
[16:01] <mathiaz> mebrown: hi - I'm currently investigating bug 598030
[16:02] <mathiaz> mebrown: is there anything in the code that would make things harder?
[16:02] <mebrown> not really.
[16:02] <mathiaz> mebrown: is inventory_firmware_gui the only bit that call anything gui related?
[16:02] <mebrown> they are separate bins
[16:02] <mebrown> I think so.
[16:02] <mathiaz> mebrown: IIUC inventory_firmware_gui is just a GUI frontend that call the cli scripts?
[16:03] <mebrown> no
[16:03] <mebrown> separate implementation that uses the backend python libs
[16:03] <mebrown> shares same libs as the cli, but does not use
[16:03] <mathiaz> mebrown: gotcha
[16:03]  * mathiaz nods
[16:03] <mathiaz> mebrown: do you have an opinion on the package names?
[16:04] <mathiaz> mebrown: ie should the gui be split to firmware-tools-gui?
[16:04] <mathiaz> mebrown: that would require desktop users to install firmware-tools-gui instead of firware-tools
[16:04] <mathiaz> mebrown: I wonder what's the impact on existing documentation
[16:04] <mebrown> mathiaz, no real strong opinions.
[16:05] <mathiaz> mebrown: or users expects to have a gui when installing firmware-tools?
[16:05] <mebrown> mathiaz, would like it if all the pkgs could use the same convention, though. (rpm/deb/etc)
[16:05] <mathiaz> mebrown: is there already a split for rpm packages?
[16:05] <mebrown> no.
[16:06] <mebrown> would probably need to split into something like: firmware-tools-libs, firmware-tools-cli, firmware-tools-gui
[16:06] <mebrown> and have firmware-tools be a meta-pkg for backwards compat
[16:06] <mathiaz> mebrown: ok - s/-libs/-common/
[16:07] <mebrown> I dont really have a clear idea if most people use the cli or gui. I suspect that most people use cli, but no hard data
[16:07] <mebrown> -common works for me
[16:07] <mathiaz> mebrown: so firmware-tools-common, firmware-tools-cli, firmware-tools-gui and firware-tools depending on firware-tools-gui
[16:07] <mathiaz> mebrown: as a transitional package
[16:07] <mebrown> sounds fine to me. probably want f-t to depend on both f-t-g and f-t-c
[16:08] <mathiaz> mebrown: great - thanks for your input
[16:08] <tumbleweed> if anyone is doing anything about firmware-tools, dell probably needs a prod. It looks like their firmware repository is in poor shape
[16:09] <mebrown> tumbleweed, yes, I know.
[16:09] <mebrown> its mine and I'm catching up on all my projects now
[16:09] <mebrown> spent a year in limbo working on... just a sec, let me get the link.
[16:10] <tumbleweed> a cool. I was the last person to touch firmware-tools here, and found it to be rather unhappy
[16:10] <mebrown> http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2010/07/27/dell-openmanage-6-3-for-ubuntu.aspx
[16:11] <mebrown> got a funny message from the blog team this morning: Why does your blog post have two orders of magnitude more views than any of the other stories?
[16:13] <ScottK> pitti: Would you please rescore xine-lib.  It just affects powerpc and ia64 and should save us some retries on those archs to get it built now.
[16:21] <pitti> ScottK: sure, doing
[16:21] <ScottK> pitti: Thanks.
[16:25] <zul> ptti: acked
[16:53] <zul> pitti: done
[17:33] <LucidFox> seb128, I have talked to ritz about releasing xchat-gnome 0.26.2 - he says he plans to finalize and commit by Wednesday.
[17:33] <LucidFox> So hopefully we'll be able to get it in before FF
[17:33] <seb128> hey LucidFox
[17:33] <seb128> ok
[17:43] <LucidFox> Is f-spot going to be demoted to universe now that shotwell is in main
[17:43] <LucidFox> ?
[17:44] <chrisccoulson> LucidFox, no
[17:56] <jono> are others finding that evolution is crashing a lot?
[18:02] <ebroder> I haven't been using it too extensively, but not really
[18:03] <jono> it is crashing every few messages for me
[18:03] <ebroder> Yeah, definitely not that bad
[18:32] <pitti> zul: can you please reupload with referring the two regression bugs in the changelog, and include all three -proposed uploads in -v?
[18:32] <pitti> zul: please check the _source.changes, it should have three records
[18:32] <zul> pitti: k
[18:33] <ScottK> pitti: Would you please rescore libmpc - need that one apparently before I need xine-lib.
[18:33] <pitti> ScottK: done
[18:34] <ScottK> pitti: Thanks.
[18:54] <zul> pitti: done
[19:00] <pitti> zul: still don't see it -- was the upload successful? (old ".upload already exists" trap?)
[19:00] <zul> gah....shakes fist
[19:31] <bdrung> how can i determine, who of the archive-admin team rejected an upload?
[19:33] <pitti> bdrung: nobody can
[19:34] <pitti> bdrung: the convention is that the archive admin sends the reason to the uploader and CC:s ubunt-archive@
[19:34] <pitti> or does a bug followup in the case of a rejected SRU
[19:34] <Laney> bdrung: are you talking about projectm?
[19:34] <bdrung> Laney: yes
[19:35] <Laney> That was ScottK: the maintainer spoke up in #-motu about this version being unsuitable
[19:35] <Laney> see scrollback there for the discussion
[19:36] <ScottK> bdrung: You were highlighted at the end of the discussion.
[19:36] <pitti> zul: was an identical double-upload, so I reject one; don't get scared
[19:36] <zul> pitti: hehe thanks
[19:36] <pitti> zul: oh, but can you please reupload with the to new bug refs in the latest changelog?
[19:37] <zul> pitti: sure
[19:37] <pitti> zul: 611101  and 611102
[19:37] <bdrung> ok, thanks
[19:41] <zul> pitti: uploaded
[19:53] <pitti> zul: thanks, looks good; can you upload to maverick, too?
[19:53] <zul> yeps as soon as im done with what im working on
[19:53] <pitti> thank you
[19:56] <pitti> so, that (hopefully) closes the 10.04.1 SRUs
[20:42] <jono> folks, evolution keeps crashing for me when I want to reply to an email, it seems to do it every few messages - I run it in a terminal but it just says it is a segfault - how can I get better debug info?
[20:42] <jono> (in Maverick)
[20:44] <BlackZ> jono: I think you could try to install evolution-dbg
[20:48] <jono> thanks BlackZ - what is that?
[20:50] <BlackZ> jono: that package contains debugging symbols for evolution, http://live.gnome.org/GettingTraces/Details
[20:54] <jono> thanks BlackZ
[21:04] <Chipzz> BlackZ: eh? why are you redirecting him to a gnome.org page when ubuntu has apport??
[21:05] <BlackZ> Chipzz: if he wants to do a bug report against the ubuntu package then he can use apport, but it's better to report it to gnome too
[21:05] <Chipzz> BlackZ: yes, but the ubuntu bug will get forwarded to gnome bugzilla anyway
[21:06] <BlackZ> Chipzz: FYI someone will have to
[21:06] <Chipzz> and someone will
[21:06] <Chipzz> but
[21:07] <Chipzz> evolution-dbg only contains debugging symbols for evolution
[21:07] <Chipzz> what if the problem is in an underlying library?
[21:08] <Chipzz> I don't know the official pov from ubuntu, but my gut feeling tells me it's better to use apport/ddebs
[21:08] <pitti> the retracers install ddebs for every depending lib
[21:08] <pitti> once the retracer kicked in and produced a good stack trace, it's ready for upstream forwarding, yes
[21:08] <pitti> before that it's just a nuisance for upstream
[21:12] <BlackZ> Chipzz: evolution-dbg will collect the useful debug *for* evolution and you have to see if with that the stack trace provides enough informations. However yes, he can use apport
[21:14] <micahg> BlackZ: not necessarily, depends on what other components are involved in the error
[21:15] <BlackZ> jono: could you please check in malone/gnome if there's a bug against that?
[21:16] <Chipzz> pitti: what's the recommended approach for filing bug reports? apport or the approach BlackZ suggested?
[21:17] <Chipzz> (as an aside, I am more than a little surprised jono of all ppl did not know about apport.. :P)
[21:17] <Chipzz> pitti: also, since jono is running maverick (a development release), shouldn't apport have been enabled by default?
[21:18] <BlackZ> micahg: exactly
[21:21] <pitti> Chipzz: the easiest is to report the crash through apport, wait until the retracer got to it, and then poke people to forward it upstream and/or fix it
[21:21] <pitti> might be something simple
[21:21] <pitti> Chipzz: yes, maverick has apport enabled
[21:23] <jono> Chipzz, I know about apport, but it is not triggering when it crashes
[21:24] <pitti> jono: do you get apport on: sh -c 'kill -SEGV $$'
[21:24] <pitti> ?
[21:24] <SpamapS> mathiaz: agreed better here...
[21:24] <SpamapS> mathiaz: so .. collectd plugins.. what would you say to splitting it into its own source package, much like php-imap does?
[21:24] <SpamapS> mathiaz: at issue is the list of MIR-needing libs .. if we can just leave the plugins that need those libs out of main .. *win*
[21:25] <mathiaz> SpamapS: both packages would have the same .orig.tar.gz though?
[21:25] <SpamapS> mathiaz: otherwise we need to pile even more stuff onto the already massive main seed.. libesmtp, libconfuse, libganglia ...
[21:25] <SpamapS> mathiaz: right
[21:25] <mathiaz> SpamapS: the other solution is to disable the unwanted plugins during build time
[21:26] <SpamapS> mathiaz: that would be a disaster
[21:26] <SpamapS> mathiaz: "We support collectd now, but we had to turn off half of the cool features."
[21:26] <SpamapS> The reason we want it in main is for uec...
[21:26] <SpamapS> so we should be able to just bring what we want for uec, into main, and leave the rest in universe.
[21:27] <mathiaz> SpamapS: right - as a monitoring agent for UEC components
[21:27] <SpamapS> one issue with that is that the plugins can only be in "suggests" ..
[21:27] <mathiaz> SpamapS: rather than a monitoring agent for instances running into the cloud
[21:27] <SpamapS> so users will install the collectd package, and then wonder why it doesn't have all the plugins they want.
[21:27] <SpamapS> But one way to get around that..
[21:28] <SpamapS> is to have collectd-basic in main .. used by uec and whatever else needs it, but then the actual 'collectd' package is in universe.
[21:28] <mathiaz> SpamapS: right - having a collectd-core in main
[21:28] <Chipzz> jono: shouldn't it? maybe you have it disabled?
[21:28] <SpamapS> core, that sounds much better. :)
[21:28] <mathiaz> SpamapS: (rather than -basic)
[21:28] <mathiaz> SpamapS: so IIRC there was a similar issue with xen
[21:29] <mathiaz> SpamapS: where xen was in main but only to have the -dev package
[21:29] <mathiaz> SpamapS: in main
[21:31] <mathiaz> SpamapS: yes - xen-3.3 is in main
[21:32] <mathiaz> SpamapS: http://packages.ubuntu.com/source/lucid/xen-3.3
[21:32] <mathiaz> SpamapS: however the hypervisor and the tools are in universe
[21:32] <jono> Chipzz, it should, I am not sure why it isn't - how do I check
[21:32] <mathiaz> SpamapS: and only libxen3-dev is in main
[21:32] <mathiaz> SpamapS: because of libvirt
[21:33] <BlackZ> agreed with pitti: you could report it with apport against the ubuntu package and then report it to upstream (gnome, in this case). But if you just want to get the debug symbols, you can use the debug symbols for the respective packages (e.g. evolution-dbg for evolution)
[21:34] <mathiaz> SpamapS: so that's another option - it may make the MIR processing easier
[21:34] <SpamapS> mathiaz: my main concern is actually just the explosion of responsibility we're accepting in main
[21:34] <micahg> BlackZ: the problem is that since we use system libs for most packages, you'll get a partial trace using the package-dbg packages
[21:36] <Chipzz> jono: if you have it disabled? I think some file in /etc/default (if I'm not mistaken)
[21:37] <jono> Chipzz, I have it now, it was removed from my panel
[21:37] <jono> thanks
[21:38] <mathiaz> SpamapS: so the collectd dependencies that would need to be promoted to main are: 'collectd', 'libdbi', 'libesmtp', 'liboping', 'memcached', 'libmemcached', 'yajl'
[21:38] <mathiaz> SpamapS: memcache is already done
[21:38] <SpamapS> mathiaz: memcached+libmemcached are already approved to main
[21:39] <mathiaz> SpamapS: libdbi on its way because of rrdtool?
[21:39] <SpamapS> mathiaz: and libdbi should make it due to rrdtool's dependence (and its relative stability)
[21:39] <SpamapS> mathiaz: libganglia1 is also needed
[21:39] <pitti> good night everyone
[21:40] <mathiaz> SpamapS: hm - right - it seems that my script fails
[21:40] <BlackZ> micahg: that's true too but not always, first we should try to collect the debug information and see if they're partial, agreed?
[21:40] <mathiaz> SpamapS: because rrd-dev is currently unstalable in maverick
[21:40]  * mathiaz tries on lucid
[21:41] <SpamapS> mathiaz: librrd-dev > 1.4 is , I think, the build-dep for the latest collectd
[21:42] <SpamapS>  librrd-dev (>= 1.4~),
[21:42] <mathiaz> SpamapS: so on lucid the list is: 'collectd', 'confuse', 'libdbi', 'libesmtp', 'ganglia', 'liboping', 'memcached', 'libmemcached', 'yajl'
[21:42] <SpamapS> mathiaz: 1.4 isn't uploaded, though I did do the merge. I think its awaiting merge-proposal-review by ubuntu-server. ;)
[21:43] <SpamapS> https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/rrdtool/merge-1.4.3-1/+merge/30675
[21:43] <mathiaz> SpamapS: it seems that libesmtp liboping could be disabled
[21:44] <SpamapS> mathiaz: liboping I believe is the baseline ping monitor. Not needed for uec, but a huge need by your average collectd user
[21:45] <mathiaz> SpamapS: the library seems quite simple - so could be easy to MIR
[21:45] <mathiaz> SpamapS: I think the main one would be ganglia
[21:45] <micahg> BlackZ: requires debugging twice, vs 1 apport crash
[21:47] <BlackZ> micahg: yeah, so as pitti said using apport is the easiest way
[21:47] <micahg> BlackZ: even if people want privacy and won't upload a coredump, they can retrace the apport crash (which can also install all the appropriate -dbgsym packages) locally, it's really an awesome tool
[21:47] <SpamapS> mathiaz: agreed, ganglia's only non main dependency is libconfuse
[21:48] <mathiaz> SpamapS: ok - and ganglia itself would be a huge effort to MIR
[21:48] <mathiaz> SpamapS: I'm not sure we want that in main
[21:49] <BlackZ> micahg: yes
[21:49] <SpamapS> mathiaz: ganglia could just have libganglia1 in main
[21:50] <mathiaz> SpamapS: yeah - that would be an option - similarly to what we do for xen
[21:50] <SpamapS> mathiaz: but I'd rather do even more to reduce the burden on main by moving the bulk of the optional plugins to a non-main package
[21:51] <mathiaz> SpamapS: well - we'd increase our burden by splitting source packages
[21:51] <mathiaz> SpamapS: as we'd have to update collectd-plugin whenever collectd is updated
[21:52] <SpamapS> mathiaz: right, I think we have more merge-bandwidth than we do security-bandwidth. ;)
[21:53] <mathiaz> SpamapS: hm - well - the split proposal is much more unusual
[21:53] <mathiaz> SpamapS: I don't know of any package where we do that
[21:54] <mathiaz> SpamapS: I'd send an email to ubuntu-devel to ask for feedback on the two options
[21:54] <mathiaz> SpamapS: I'd lean towards including ganglia into main personally
[21:56] <SpamapS> mathiaz: meh.. munin, collectd, and ganglia, all in main.. ;)
[21:58] <mathiaz> SpamapS: right
[21:58] <mathiaz> SpamapS: we'll sort things out during the next UDS
[21:58] <mathiaz> SpamapS: to get everything in order for the next LTS
[22:02] <SpamapS> mathiaz: I think we should have a *very* clear picture of what the next LTS looks like, server wise, by the end of UDS-O
[22:03] <SpamapS> mathiaz: we can't wait for P. :)
[22:06] <mathiaz> SpamapS: we should discuss that at UDS-N then
[22:07] <SpamapS> Yeah I have my UDS-N ideas brewing now. :)
[22:08] <mathiaz> SpamapS: awesome - don't forget to *capture* them
[22:09] <SpamapS> mathiaz: rememberthemilk.com is turning out to be perfect for that
[22:10] <mathiaz> SpamapS: http://brainstorm.ubuntu.com/ as well :)
[22:11] <SpamapS> mathiaz: a difficult step for me is clarify.. I'm such a pack-rat.. I never want to delete anything. ;)
[22:19] <SpamapS> can somebody who moderates ubuntu-devel please take a look at the posting I just did<EMAIL_ADDRESS>"MIR for collectd requires some guidance") and accept/reject it. The last message I sent to ubuntu-devel sat unmoderated for 3 weeks. ;)
[22:31] <rsavoye> is there a bzr branch on launchpad for OpenJDK ?
[22:32] <rsavoye> that is the source, not just packaging files
[22:34] <SpamapS> rsavoye: I don't know where the official upstream for openjdk is, but lp:ubuntu/openjdk should be the current development package w/ the source.
[22:35] <rsavoye> there is nothing at that url, I tried
[22:35] <rsavoye> java.net has a mercurial repository, but you have to be registered to access it
[22:37] <micahg> rsavoye: apparently a default branch isn't registered for that source, can you file a bug on bugs.launchpad.net/udd ?
[22:37] <rsavoye> sure, but I need it now! :-)
[22:37] <micahg> it should be lp:ubuntu/openjdk-6
[22:38] <rsavoye> should be... openjdk6 has the packaging files, nothing else that I can find
[22:44] <micahg> seems to be stopped on bug 513215
[22:51] <rsavoye> ah, I see, it mentions openjdk-6 as an affected package. Oh well...
[22:52] <rsavoye> well, now there are two of us the bug effects :-)
[23:41] <wgrant> barry: Hi.
[23:43] <wgrant> barry: AFAICS, both system-config-printer builds have a non-None current_source_publication. That's how you're meant to get the source details.


[20:45] <dekarl> superm1: rsyslog for 0.26 with mythlogserver works like this
[20:45] <dekarl> if $msg startswith ' mythbackend' then /var/log/mythtv/mythbackend.log
[20:45] <dekarl> notice the leading space in $msg
[20:49] <superm1> dekarl: so that conf file needs updating then basically?
[20:49] <superm1> i haven't ran anything on 0.26 yet, so i don't have a good feel for everything broke thus far
[20:50] <dekarl> aye, basically duplicate all rules in the "$msg startswith ' xxx'" form in addition to "$programname == 'xxx'"
[20:51] <dekarl> so one config file will work with 0.25 and 0.26
[20:51] <superm1> oh i guess that's possible - you think it's better to have the same config for both?
[20:51] <superm1> i was gonna say just switch it out all together, no need to keep teh 0.25 syntax in
[20:52] <superm1> just do http://paste.ubuntu.com/1110869/
[20:52] <Zinn> [paste.ubuntu.com] Ubuntu Pastebin
[20:53] <dekarl> is the configuration file part of a mythtv version specific file or does it go with the {u,myth}buntu release specific files? in the former case just change it, in the latter case it should be duplicated
[20:54] <superm1> well it's the same file name when the user upgrades from 0.25 to 0.26, but the package manager will just update teh conffile as long as you haven't changed it yourself
[20:55] <superm1> if you changed it yourself, it's gonna require intervention either way it's done
[20:57] <dekarl> ahh, I see. its in mythtv-common_0.26.0~master.20120725.643ad3e-0ubuntu1_amd64.deb. so just replace the lines and thats it
[20:58] <superm1> exactly
[20:58] <superm1> i'll commit that
[20:59] <superm1> okay, should be in tonight's build now
[21:00] <dekarl> ok, building now (seems your commit is already in)
[21:02] <superm1> is there anything else with the logging that needs fixing?
[21:02] <dekarl> nothing that I know of. maybe fixup the "last message repeated 10 times" but unfolding the copies is not getting us more information so I'd skip it
[21:03] <superm1> cool.  yeah i think that it's more useful the way it's setup
[21:04] <superm1> i committed your recmnded fix from #mythtv too for how to set up that buffer
[21:04] <superm1> good call
[21:05] <dekarl> I just stumbled over the suggested filename when looking if there is a sysctl.d similar to rsyslogd after hearing of the sysctl.conf file
[21:06] <dekarl> I was positively surprised to find a README file explaining how its meant to work in there :)
[21:11] <superm1> yeah i'm glad that readme explains the numbering to use as well
[21:20] <dekarl> superm1: you missed mythfrontend?
[21:23] <dekarl> hm, we could replace "#012" with "\n" in lines like http://paste.ubuntu.com/1110913/
[21:23] <Zinn> [paste.ubuntu.com] Ubuntu Pastebin
[21:50] <superm1> dekarl: whoops, good catch
[21:50] <superm1> dekarl: do you know how to switch out the #012 with new lines like that?
[21:50] <dekarl> not yet, was just thinking out aloud to see how it sounded
[21:51] <dekarl> might also strip the "mythlogserver: "
[21:51] <superm1> yeah i think stripping the mythlogserver: would  be a good idea
[21:51] <dekarl> before and after http://code.mythtv.org/trac/ticket/10729
[21:52] <Zinn> [code.mythtv.org] #10729 (HTTP Live Streaming not following IETF standard) â MythTV
[21:52] <dekarl> meh http://paste.ubuntu.com/1110951/
[21:52] <Zinn> [paste.ubuntu.com] Ubuntu Pastebin
[21:57] <superm1> well that looks readable, that's with the #012->\n filtering?
[22:01] <dekarl> no, just a sample for the "mythlogserver: "
[22:02] <dekarl> which reminds me that the apport handler should strip all but the last run from the logfiles
[22:09] <superm1> oh yeah that looks better with the mythlogserver: stuff gone


[10:10] <AlanBell> kwwii: hi, will you be going to UDS?
[10:11] <AlanBell> kwwii: the #gally project is looking for a photographer for a photoshoot at UDS of images for a sign language tutorial application
[12:45] <kwwii> AlanBell: no, I will not be at UDS this time
[12:56] <AlanBell> ok, neither will I :(
[13:04] <AlanBell> I will be sat at home playing http://ubingo.libertus.co.uk :)
[16:34] <markben> I'm a web developer running Ubuntu that wants to start using Inkscape/GIMP to do my website mockups.  Anyone have advise on getting started and what a good workflow is?
[16:48] <thorwil> markben: hi! hmmm ...
[16:49] <thorwil> markben: working in inkscape allows you much better control over shapes and gradients. things can remain flexible
[16:50] <thorwil> markben: this is about ui mockups, but might contain something useful to you: http://mairin.wordpress.com/2010/08/02/creating-ui-mockups-in-inkscape-video-tutorial/
[16:51] <markben> thorwil: Thanks!  That's exactly the kind of thing I was looking for! :)
[16:52] <thorwil> markben: set the grid to 1px spacing. # key toggles grid visibility. also make use of coordinates and width/height in the toolbar to keep things on the pixel grid for sharp results
[16:53] <markben> thorwil: Good tip.  I'd read that some of the exported images can be a bit fuzzy sometimes.  That sounds like a good solution.
[16:55] <thorwil> markben: the Export dialog has a batch feature. say you want to slice your page into parts: use a layer where you place rectangles in the right places and sizes. then when you want to export, lock other layers, select all in that layer and use the batch export option. best to do a dry-run to get it
[16:56] <thorwil> markben: do you code PHP and/or Python, Ruby ... ?
[16:57] <markben> thorwil: Ruby with a little Python on the side.  I run our local Ruby usergroup and need to give our site a facelift. :)
[16:57] <markben> thorwill: http://yegrb.com
[17:04] <thorwil> i see :)
[17:05] <markben> Is there a simple quick
[17:05] <markben> way to share screenshots on Ubuntu?
[17:05] <markben> I've seen an app which takes an image on your computer and returns a short-url to it with one click on Mac but I can't remember what it was called.
[17:06] <markben> I'm looking for an Ubuntu alternative but google is failing me without a name for the app.
[17:08] <thorwil> perhaps http://shutter-project.org ?
[17:08] <thorwil> though it looks like it does a lot more and has no such one-click feature
[17:10] <markben> thorwil: Thanks.  That looks like it will do what I need.  I'm just looking a for an easy way to share screenshots with some other members.
[17:10] <thorwil> markben: well, try ubuntu-one?
[17:12] <markben> thorwil: I tried ubuntu-one last year and didn't find it synced very well for me.  I also need something with clients for Mac and Windows.  I'm willing to try it again though and see if it's improved as I'd rather use UbuntuOne than Dropbox.
[17:13] <markben> Anything I can do to support Ubuntu development is a priority in my books. :)
[17:13] <markben> thorwill: Do you have an example of using the Export dialog as you described.  I'm just trying that now.
[17:14] <thorwil> i admit that i was disappointed by ubuntu one and use dropbox
[17:14] <thorwil> but the support/availability would be an argument in favor of it, if all involved use ubuntu
[17:15] <markben> thorwil: Unfortunately at this point I'm the vangaurd of Ubuntu at the meetup, though I've been getting a lot of questions about it.
[17:16] <markben> thorwil: Most of my members have begun using Ubuntu server in a VM for Ruby development.
[17:18] <thorwil> markben: regarding support, i guess spreadubuntu or the ubuntu manual project could use a helping hand ;)  though not ruby in either case
[17:20] <markben> thorwil: I've been contributing translations to the Canadian english local.  I'm looking at contributing to Shotwell or Kazam.
[17:21] <markben> thorwil: I like the idea of working on things that share the progress Ubuntu has made in the look-and-feel department.
[17:22] <markben> thorwil: FYI, I think I just got the batch export option working in Inkscape with the selected rectangles you described.
[17:22] <markben> thorwil: That tip will save a tonne of time! Thx!
[17:22] <thorwil> markben: np :)
[17:23] <markben> thorwil: My lunch break is over now though.  Got to get back to some *real* work.  TTYL!
[22:09] <popey> I'm guessing most of you are on the list already, but if not https://lists.ubuntu.com/archives/ubuntu-art/2010-October/012357.html


[08:15] <Mechtilde> https://bugs.launchpad.net/ubuntu/+source/calendar-exchange-provider/+bug/1203433
[08:16] <Mechtilde> what can I also do, to  push on?