[00:11] <jcastro> anyone know anything about libtheora? Seems we just get it from debian
[00:18] <slangasek> jcastro: is there more to know than "it's the lib that implements the codec"?
[00:20] <jcastro> slangasek: yeah it's just recently it's been a contentious issue with browsers, etc. upstream, I think it would be great if for karmic we had it nice and fresh
[00:20] <jcastro> "open web" and all that
[00:20] <slangasek> hrm?
[00:20] <jcastro> so, new browsers support the <video> tag
[00:21] <jcastro> so you can just embed videos
[00:21] <slangasek> what do you mean by "nice and fresh"?
[00:21] <jcastro> and mozilla and others have been sponsoring theora development
[00:21] <jcastro> the current dev branch "thusnelda" brings a bunch of improvements to the encoder
[00:21] <jcastro> to make it more competitive for web video
[00:22] <jcastro> and I was just wondering if someone is keeping an eye on it (PPA or otherwise), so that for 9.10 we're not behind as far as a platform for people who want to encode theora video
[00:22] <ajmitch> I take it there's no new release of it yet?
[00:22] <jcastro> slangasek: keeping in mind that this didn't really seem important until like, last week
[00:22] <jcastro> ajmitch: it's in alpha2
[00:23] <slangasek> that's the 1.1 branch, then?
[00:23] <jcastro> slangasek: that would be the alpha one I am referring to
[00:58] <billybigrigger> anyone know when the gtk2.0 problems will be sorted?
[01:01] <slangasek> billybigrigger: what problems?
[01:01] <billybigrigger> the constant seg faulting
[01:01] <slangasek> where has this been reported?
[01:01] <billybigrigger> im pretty sure, lemme check
[01:02] <billybigrigger> libgtk2.0
[01:02] <billybigrigger> i can crash deluge, transmission all day just by trying to change where i save my torrent's
[01:02] <billybigrigger> also im pretty sure my constant nautilus crashes are also caused by gtk2.0
[01:03] <billybigrigger> can't seem to find a bug related to it, so ill file one
[01:03] <slangasek> that would be the first step.
[01:03] <slangasek> please use apport, so that we can actually see where this crash is happening.
[01:03] <billybigrigger> libgtk-x11-2.0.so to be more specific
[01:03] <billybigrigger> Jun 18 17:53:43 cabo kernel: [174822.185657] deluge[7151]: segfault at c0cc100 ip 00007f642a4b1e59 sp 00007fff1696da40 error 4 in libgtk-x11-2.0.so.0.1702.0[7f642a3fc000+43e000]
[01:04] <billybigrigger> Jun 18 17:54:33 cabo kernel: [174872.489733] transmission[17614]: segfault at 640114e0 ip 00007fac754b9e59 sp 00007fff34c7c750 error 4 in libgtk-x11-2.0.so.0.1702.0[7fac75404000+43e000]
[01:05] <slangasek> yes, please use apport to file a bug that shows us the backtrace.  kernel messages don't give enough information to debug
[01:05] <slangasek> or even to match your crash up with other reports
[01:07] <billybigrigger> and what about this whole empathy thing, like why is it replacing pidgin? empathy doesn't use libnotify or notifications, and is bugged all to hell, i can start it up, see 0 contacts online, and fire up pidgin and see 10+ contacts online...
[01:09] <billybigrigger> apport won't even fire up
[01:09] <billybigrigger> when i crash deluge or transmission
[01:09] <billybigrigger> so i guess the crash log from /var/crash will have to do
[01:10] <slangasek> yes, you should be able to use apport-cli -c /var/crash/crashfile to pick it up.
[01:37] <DreadKnight> i'm running kubuntu.. recently pidgin doesn't connects to my yahoo account...
[01:38] <DreadKnight> i wanted to try empathy and it kept asking for a stupid password in order to connect to the accounts imported from pidgin automatically.. that was epic fail
[01:39] <DreadKnight> i removed empathy... now yahoo is not working... I don't recall any recent updates to pidgin or libpurle
[01:39] <DreadKnight> my guess is that empathy messed it up
=== Snova_ is now known as Snova
=== lex79 is now known as lex79_
=== lex79_ is now known as lex79
=== rgreening_ is now known as rgreening
[05:59] <Syrius> hello
[05:59] <Syrius> can you ask questions in here ?
[05:59] <tgpraveen> Syrius: develop related ques yes
[06:02] <Syrius> okay cool tgpraveen
[06:02] <Syrius> I have newbie questions tgpraveen
[06:02] <Syrius> about pbuilder
[06:02] <Syrius> hold on
[06:03] <Syrius> let me see what my question exactly is
[06:07] <Syrius> so once you make the debian packages you just install the ones in /var/cache/pbuild/result ? tgpraveen
[06:08] <Syrius> with pbuilder
[06:08] <tgpraveen> sorry am a noob too maybe someone else could help you here
[06:09] <Syrius> okay
[06:10] <TheMuso> Syrius: #ubuntu-motu would like be a better place to ask.
[06:10] <TheMuso> likely
[06:10] <Syrius> what does that stand for?
[06:11] <Syrius> motu?
[06:34] <TheMuso> Syrius: thats the IRC channel where you will most likely get the answers to your questions.
[06:56] <dholbach> good morning
[08:23]  * nixternal hugs dholbach 
[08:24] <MacSlow> Greetings everyone!
[08:28] <tgpraveen> is there a ppa for the messaging indicator so that I can get the empathy support for it( which is available in karmic ) in jaunty
=== mthaddon is now known as afk
=== tkamppeter_ is now known as tkamppeter
[08:42]  * dholbach hugs nixternal back
[09:11] <hyperair> does anyone know how long it usually takes for a NEW package to get synced from Debian?
[09:14] <pitti> Good morning
[09:15] <pitti> MacSlow: seems we need to update dk-p then
[09:17] <MacSlow> pitti, wait...
[09:17] <MacSlow> pitti, I just pulled all updates (800+ MBytes) and now it compiles
[09:17] <pitti> MacSlow: we do have 2.27.1 in karmic, though
[09:17] <pitti> and it builds fine
[09:17] <MacSlow> pitti, yes
[09:17] <MacSlow> pitti, I have no clue was different though
[09:18] <MacSlow> just happy it works and I don't have to enter dependency-hell
[10:20] <kwah> hi all
[10:21] <kwah> whom may I contact with respect to tools available to create generic Ubuntu add-on CD?
=== smb is now known as smb_afk
[11:13] <tseliot> pitti: about dealing with the blacklist file directly in the broadcom package (instead of the Jockey handler). What do you think about doing it in the postinst? https://pastebin.canonical.com/18727/
[11:13] <tseliot> pitti: this part "if [ ! -f $BLACKLIST_FILE ]; then" is what does what I said
[11:17] <tseliot> and of course there will also be a postrm which removes the file
[11:18] <pitti> tseliot: that would work, since it would avoid conffiles staying around if you remove, but not purge
[11:19] <pitti> tseliot: but why don't you blacklist b43 in the "b44" case, and b43legacy in neither case?
[11:20] <pitti> tseliot: you should also blacklist ssb, and (just in case you are running an older kernel), bcm43xx
[11:20] <pitti> tseliot: similar to what the current jockey handler is doing
[11:20] <pitti> tseliot: but I do like the packaging approach
[11:22] <lucas> seb128: have you seen the thread on debian-devel@ about patch tagging guidelines?
[11:22] <lucas> seb128: since you did the original work on the ubuntu policy, it might be interesting for your to take a look
[11:23] <lucas> seb128: the current debian proposal is incompatible with the ubuntu one
[11:23] <seb128> lucas: ubuntu-devel got emailed about that I did read the email
[11:23] <lucas> ah ok
[11:23] <tseliot> pitti: yes, the script is not complete yet but thanks for the feedback. I'm glad to read that you like the approach.
[11:33] <tseliot> pitti: ok, this version does exactly what jockey does. Shall I still call /usr/sbin/update-initramfs -u? https://pastebin.canonical.com/18728/
[11:42] <pitti> tseliot: initramfs> yes, you need to, so that the driver isn't accidentally loaded in initramfs
[11:43] <tseliot> pitti: ok, thanks
=== ember_ is now known as ember
[12:01] <tseliot> pitti: one last thing. Shall I remove the blacklist file in the postrm when the postrm is passed the "upgrade" parameter too? (so that the file is regenerated when the package is upgraded)
[12:01] <pitti> tseliot: hm, I think it's only necessary on removal
[12:02] <pitti> reduces the chance to stomp over local modifications
[12:02] <tseliot> pitti: ok, good point
[12:02] <pitti> tseliot: btw, please add a comment saying "# This file is autogenerated and will be overwritten" or so
[12:03] <tseliot> pitti: sure
[12:04] <cjwatson> pitti: do you know why bug 363712 is on Steve's agenda under foundations rather than desktop?
[12:04] <ubottu> Launchpad bug 363712 in openclipart "cliparts are not in gallery-path of openoffice 3.0" [Medium,Confirmed] https://launchpad.net/bugs/363712
[12:04] <cjwatson> pitti: I know doko was the one who targeted it ...
[12:06] <pitti> cjwatson: not sure, I mention it on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[12:06] <pitti> cjwatson: probably just a glitch in the topic list
=== smb_afk is now known as smb
=== asac_ is now known as asac
=== pbn_ is now known as pbn
[13:35] <bigon> Keybuk: hi what was the reason of such changes?   * Bump build-depend on debhelper to install udev rules into
[13:35] <bigon>     /lib/udev/rules.d, add Breaks on udev to get correct version.
[13:35] <bigon> ? can these changes be dropped?
[13:36] <doko> cjwatson, pitti: this one just needs a change of directory name, or else the extra cliparts are not seen in OOo
[13:37] <Keybuk> bigon: udev rules have to be installed in /lib/udev/rules.d
[13:37] <Keybuk> bigon: dropping those changes would mean they would be installed in the wrong place
[13:37] <Keybuk> bigon: so, no
[13:38] <cjwatson> doko: if you agreed with the patch in the bug report, I'm happy to sort out uploads
=== ogra_ is now known as ogra
[13:41] <bigon> Keybuk: http://launchpadlibrarian.net/21147124/garmin-forerunner-tools_0.09-2_0.09-2ubuntu1.diff.gz << there is nothing intresting in this diff as debhelper and udev are at the good version in karmic
[13:41] <Keybuk> bigon: incorrect
[13:41] <Keybuk> bigon: the build-depends is still needed to ensure correct builds if people backport
[13:41] <Keybuk> bigon: the Breaks is still needed to support upgrades (e.g. LTS to LTS)
[13:42] <dholbach> pitti: I'm just taking a look atit
[13:42] <doko> cjwatson: yes, this looks fine (plus maybe update the dependency on OOo to >= 3.0
[13:42] <dholbach> doko: or are you done with it already?
[13:42] <dholbach> doko: ooops
[13:42] <doko> dholbach: done with?
[13:43] <bigon> Keybuk: mmm ok
[13:43] <dholbach> pitti: or are you done with it already?
[13:43] <ScottK> Keybuk: Thanks for worrying about backports.
[13:44] <pitti> dholbach: no, currently doing spec reviews; thanks
[13:44] <dholbach> pitti: I'll take over json-glib then
[13:44] <pitti> dholbach: I'm already at that one
[13:44] <pitti> about to dput it, finished building
=== korn_ is now known as c_korn
[14:12] <apw> pitti, any idea who looks after the upload janitor?  the one which moves bugs to Fix Released?
[14:12] <pitti> apw: hm, might be cprov? or at least he should know who
[14:12] <apw> hrm... i think i just found the failure ... our end ... thanks for the info
[14:14] <cprov> apw: ehe, is it also called 'janitor' ?
[14:14] <apw> heh ... no the failure it called me ... damn
[14:15] <cprov> apw: okay, ping if you need anything.
[14:18] <apw> cprov, thanks will do
=== afk is now known as mthaddon
[15:56] <lool> Err I thought (hd0,1) meant sda2, not sda1; did this change with GRUB2?
[15:57] <cjwatson> yes, it did
=== yofel_ is now known as yofel
[15:57] <lool> Geez how confusing
[15:57] <cjwatson> see http://www.gnu.org/software/grub/grub-2.en.html ("design mistakes in GRUB Legacy")
[15:58] <lool> Thanks
[15:58] <cjwatson> should mostly be using UUIDs now anyway ...
[16:20] <Riddell> mathiaz: will mysql 5.1 be in main for karmic or 5.0?
[16:24] <mathiaz> Riddell: hm - good question
[16:24] <mathiaz> Riddell: I've thinking about doing the transition
[16:24] <mathiaz> Riddell: I think that the security team wants 5.1 in main for the next LTS
[16:25] <kirkland> Keybuk: upstart question for you...
[16:25] <kirkland> Keybuk: i assume you use some sort of kernel interface to see when new processes are launched?
[16:25] <Keybuk> in upstart-nl, yes
[16:25] <kirkland> Keybuk: something more advanced than grep'ing ps or /proc, i assume?
[16:25] <Keybuk> yes
[16:25] <kirkland> Keybuk: where can i learn this magik?
[16:25] <ogra_> dutch upstart ?
[16:25] <mdz> mvo: bluez-gnome is holding  back gnome-bluetooth on my system.  is this a known upgrade issue?
[16:26] <cjwatson> ogra_: netlink
[16:26] <ogra_> ah :)
[16:26] <Keybuk> kirkland: I can tell you about it ;)
[16:26] <kirkland> ogra_: heh
[16:26] <kirkland> Keybuk: please, do
[16:26] <mdz> kirkland: it helps to be pid #1
[16:26] <Keybuk> mdz: actually, it doesn't
[16:27] <mdz> Keybuk: you just like to be contrary
[16:27] <Keybuk> kirkland: it's called the "proc connector", it's a netlink socket on which the Linux kernel sends messages about fork()/clone(), exec(), exit(), setuid(), setgid() [and hopefully by 2.6.31 if akpm gets up from under the firehose] setsid()
[16:27] <Keybuk> mdz: it's a hobby :p
[16:27] <kirkland> Keybuk: i have a new package, powernap, that i think might benefit from such an interface
[16:27] <kirkland> Keybuk: it's part of our cloud-power-management work
[16:27] <cjwatson> it *used* to help to be pid 1 ...
[16:27] <Keybuk> kirkland: in principal, you open a PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR socket
[16:28] <Keybuk> you bind to nl_family = AF_NETLINK, nl_groups = CN_IDX_PROC
[16:28] <Keybuk> then you send the kernel a secret magic message
[16:28] <mvo> mdz: not a known issue (to me), I have a look
[16:28] <Keybuk> the kernel should ACK that message
[16:28] <Keybuk> and then the firehose starts
[16:29] <kirkland> Keybuk: it's a simple python daemon that watches the process table for some list of MONITORED_PROCESSES; if none of those show up for some contiguous number of ABSENT_SECONDS, the daemon will execute a specified ACTION
[16:29] <Keybuk> http://people.ubuntu.com/~scott/forkwatch.c
[16:29] <Keybuk> is a trivial example
[16:29] <kirkland> Keybuk: with the daemon polling at a configurable INTERVAL_SECONDS
[16:29] <kirkland> Keybuk: okay, so ....
[16:29] <Keybuk> kirkland: well, firstly i'd point out that such a use case is pretty much near the top of Upstart's design goals
[16:30] <Keybuk> also the proc connector is a firehose
[16:30] <Keybuk> you receive a massive number of events
[16:31] <Keybuk> because the average Linux system spawns children like a monty python catholic
[16:31] <Keybuk> (threads are children too)
[16:31] <kirkland> Keybuk: heh
[16:31] <kirkland> Keybuk: every sperm *is* sacred
[16:33] <kirkland> Keybuk: http://bazaar.launchpad.net/~kirkland/powernap/trunk/annotate/head%3A/powernap.py
[16:33] <Keybuk>   while <condition in which PROCESS should be started> and not PROCESS
[16:33] <Keybuk>   after TIME
[16:33] <Keybuk>   exec ACTION
[16:33]  * Keybuk shrugs ;)
[16:34] <kirkland> Keybuk: so this is pretty upstarty then :-)
[16:35] <Keybuk> that's not to say it's not useful
[16:35] <Keybuk> the timescale for me getting that kind of thing working in Upstart is a lot less than the timescale for your already-written Python script ;)
[16:36] <kirkland> Keybuk: heh
[16:36] <kirkland> Keybuk: thanks for the dose of realism, then
[16:36] <kirkland> Keybuk: b/c this script is doing what we need it to do, right now
[16:36] <kirkland> Keybuk: so i am interested in this netlink interface, though
[16:37] <Keybuk> exactly, better to have software today than vapourware ;)
[16:37] <kirkland> Keybuk: your inclination is that it would be more efficient than digging through /proc/*/args ?
[16:37] <ScottK> kirkland: If you make the script ugly enough it might be motivational for upstart improvements.
[16:37] <Keybuk> kirkland: well, digging through /proc/*/args is necessary anyway
[16:37] <Keybuk> the only thing the proc connector gives you is pids
[16:37] <kirkland> Keybuk: i see, so it would eliminate my polling/sleeping
[16:37] <Keybuk> you still have to read /proc/$pid/* to figure out niceties such as process name, arguments, command line, etc.
[16:37] <Keybuk> yes
[16:38] <Keybuk> instead of polling /proc and sleeping in between, you'd continuously read from the netlink socket instead
[16:38] <kirkland> Keybuk: and fire when a new pid shows up
[16:38] <kirkland> Keybuk: if that pid's args matches one of my regexes, reset its counter to zero
[16:38] <Keybuk> I'd err on the guess that for the specific few processes you'll be monitoring, polling /proc is sufficient
[16:38] <Keybuk> it'd be more CPU/power efficient for a start
[16:38] <Keybuk> (wake up once a second, not barely off the process table)
[16:38] <kirkland> Keybuk: oh, but i'd need the polling anyway, to tell when i've met the sleep threshold
[16:39] <Keybuk> depends whether the process is likely to come and go within IDLE
[16:39] <Keybuk> which is the basic race you have
[16:41] <kirkland> Keybuk: yes, documented fairly well in the config file, though
[16:41] <kirkland> Keybuk: see the bottom of http://bazaar.launchpad.net/~kirkland/powernap/trunk/annotate/head%3A/config
[16:41] <tgpraveen1> hi which is the channel for a beginner in open source development could find help?
[16:41] <Keybuk> kirkland: if that's not a concern, I wouldn't worry about it too much
[16:41] <Keybuk> kirkland: the proc connector will obviously alleviate that concern
[16:42] <kirkland> Keybuk: sounds like a 2.0 feature for me then, as it's not a huge concern
[16:42] <Keybuk> but it's quite expensive to read, because you get a *lot* of data
[16:42] <Keybuk> now, if you want to limit the data
[16:42] <Keybuk> there's another piece of undocumented Linux functionality ;)
[16:42] <kirkland> Keybuk: i'm waking every 10 seconds right now, though in my testing, running every 1 second has no visible effect on load or powertop
[16:42] <Keybuk> for a given socket, you can upload a basic machine code program which the kernel will execute for each packet before placing it in your socket buffer
[16:43] <Keybuk> so, combine the proc connector torrent of events with a packet filter that removes everything but the specific events you're interested in
[16:43] <Keybuk> and you reduce your wakeups to something manageable
[16:43] <Keybuk> I'd also recommend using epoll() so you can edge-trigger the socket and back off further letting the data pool up
[16:44] <kirkland> Keybuk: am i just being lazy, or does that sound like overkill for the goals of powernap?
[16:44] <Keybuk> I think it's overkill :)
[16:44] <Keybuk> I think you're fine just polling /proc
[16:45] <kirkland> Keybuk: basically, if a machine hasn't seen [/usr/bin/kvm, or ssh:] in its process table for 5 minutes, pm-suspend
[16:45] <Keybuk> right
[16:45] <kirkland> Keybuk: also, what do you think of the 10 second default polling period?
[16:45] <kirkland> Keybuk: nudge that up or down?
[16:45] <Keybuk> given those processes, you're unlikely to be worried too much about missing them between polls
[16:45] <kirkland> Keybuk: right
[16:45] <Keybuk> polling proc is cheap, you don't need disk for it
[16:46] <Keybuk> you could poll every second without changing the processor wakeup I'd guess
[16:46] <kirkland> Keybuk: i'm actually testing this at home on my mythtv frontends, watch for (mplayer, vlc, xine, sshd:)
[16:46] <Keybuk> see what works for you
[16:46] <kirkland> Keybuk: cool
[16:46] <kirkland> Keybuk: as always, thanks for your time and info ;-)
[16:47] <Keybuk> hey that's ok ;)
[16:47] <Keybuk> I've been debugging somebody's machine-that-goes-ping all day
[16:48] <Keybuk> it's nice to have a distraction
[16:52] <mterry> cjwatson: Regarding the ubiquity reorg, you talk about saving history and using 'bzr mv'.  But you can't move files between branches, can you?  Is there a secret bzr command for doing so?
[16:53] <cjwatson> mterry: there's 'bzr join'
[16:53]  * mterry RTFMs
[16:53] <cjwatson> mterry: but I don't mind *quite* so much if we end up losing some file-level history from oem-config
[16:53] <cjwatson> bzr join is a bit some-assembly-required
[16:54] <cjwatson> I think it's probably fine to keep the history from the ubiquity tree (which is richer, in general) and to move in files from oem-config as necessary
[16:54] <cjwatson> bzr join is probably overkill for this
[16:54] <mterry> cjwatson: I see.  I'll try to join as possible.  Lots of it should be joinable
[16:54] <cjwatson> mterry: the thing I objected to in the last discussion was that file history from the ubiquity branch had been lost as well by moving files around in it with rm/add
[16:54] <mterry> cjwatson: Right
[16:54] <cjwatson> I suspect you might end up wasting a lot of time with the bzr join approach
[16:54] <mterry> hehe
[16:55] <cjwatson> and we'd have to use special repository formats
[16:55] <cjwatson> and you'll probably run into exciting bugs
[16:55] <cjwatson> and it may just generally not be worth it; that's my suspicion
[16:55] <cjwatson> but you asked :-)
[16:55] <mterry> cjwatson: Ah, I thought most bzr branches with recent versions were already rich-roots
[16:55] <mterry> cjwatson: I guess I see now that it's a special format
[16:56] <cjwatson> I don't think so, even --development-rich-root is still separate
[16:56]  * mterry is nostalgic for oem-config, doesn't like to see it treated as the red-headed stepchild
[16:56] <cjwatson> I believe they merge with brisbane-core, but I forget
[16:56] <mterry> cjwatson: Alright.  Well I'll forget it for now and just avoid losing ubiquity history.
[16:56] <mterry> cjwatson: Good to know about join though
[16:57] <cjwatson> we'll probably be using join for putting together debian/-only branch history with upstream
[16:58] <cjwatson> so it might be doable, if you first join into a subtree and then separately worry about moving all the files into place
[16:58] <cjwatson> you're bound to lose history from files that exist in both branches and need to be merged, though, absent some proposed bzr features that don't exist yet
[16:58] <cjwatson> so if that's interesting to you, don't let me stop you :)
[16:58] <mterry> cjwatson: Yar, natch.  But you don't mind the format requirements
[16:58] <mterry> ?
[16:59] <cjwatson> I guess it would be dealable with
[17:00] <cjwatson> we'll be on brisbane-core soon enough anyway :)
[17:00]  * mterry joins it up
[17:15] <pitti> tseliot: great work on bcmwl!
[17:16] <tseliot> pitti: thanks for your help ;)
[17:16] <mvo> Keybuk: what was it that happend to vol_id in karmic? is it in a different package now? or replaced by something else?
[17:16] <Keybuk> mvo: replaced by blkid
[17:16]  * mvo updates ubuntu-vm-builder 
[17:17] <tgpraveen1>  hi which is the channel for a beginner in open source development could find help?
[17:17] <superm1> pitti, can you take a look an at LPIA FTBFS for bcmwl?  it's borking out in dh_strip, not sure if it's a problem in dh_strip or with the way the build was done for bcmwl
[17:17] <superm1> http://launchpadlibrarian.net/28118134/buildlog_ubuntu-karmic-lpia.bcmwl_5.10.91.9%2Bbdcom-0ubuntu1_FAILEDTOBUILD.txt.gz
[17:21] <pitti> superm1: will do (in meeting ATM)
[17:22] <superm1> pitti, thanks
[17:22] <pitti> superm1: pkg-create-dbgsym acting up
[17:22] <superm1> tseliot, it's possible you might be able to work around that FTBFS by just installing wlc_hybrid.o_shipped_x86_64 on amd64, and wlc_hybrid.o_shipped_i386 on lpia and i386
[17:23] <pitti> meh, but only on lpia :/
[17:25] <mvo> Keybuk: thanks
[17:25] <tseliot> superm1: ok, if you're sure that this can solve the problem I can work around it in the debian/rules so that it generates a different install file from the .in file according to the architecture
[17:27] <superm1> tseliot, assuming it's only going to bork out on that one file during lpia, that should work around it.  you can check by uploading to a PPA I think.  (assuming pkg-create-dbgsym runs on PPAs too)
[17:27] <superm1> or if you build an lpia pbuilder with pkg-create-dbgsym installed
[17:29] <pitti> superm1: it doesn't, but you can fake it by adding it as a build dep
[17:30] <tseliot> pitti: by adding what package?
[17:30] <pitti> tseliot: if you want to test workarounds in a PPA, add a b-dep on pkg-create-dbgsym
=== rickspencer3 is now known as rickspencer3-afk
[17:31] <tseliot> ok, thanks, I'll try it
[17:35] <mathiaz> slangasek: regarding the sru for hardy 8.04.3 - looking that bug for samba and redhat cluster suire
[17:35] <mathiaz> slangasek: *suite*
[17:36] <slangasek> thanks
[17:36] <mathiaz> slangasek: bug 290399 and bug 328874
[17:36] <ubottu> Launchpad bug 290399 in redhat-cluster "After ran the command fence_tool dump, the fenced process will take 100% CPU usage" [High,Fix committed] https://launchpad.net/bugs/290399
[17:36] <ubottu> Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Fix committed] https://launchpad.net/bugs/328874
[17:36] <mathiaz> slangasek: I don't see how we can verify them
[17:36] <mathiaz> slangasek: we don't have access to the necessary envrionement
[17:36] <slangasek> oh?
[17:36] <mathiaz> slangasek: bug 290399 - Test Case description: This is difficult to reproduce as it supposes a full RHCS setup and hitting the situation where those daemons enter the loop.
[17:37] <mathiaz> slangasek: how can this be verified?
[17:37] <slangasek> 1) set up a full RHCS setup ... :(
[17:37] <mathiaz> slangasek: bug 328874
[17:37] <ubottu> Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Fix committed] https://launchpad.net/bugs/328874
[17:37] <mathiaz> slangasek: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/328874/comments/10
[17:37] <ubottu> Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Fix committed]
[17:37] <mathiaz> slangasek: the reporter doesn't have access to the domain controller anymore
[17:38] <slangasek> mathiaz: he says the patch itself is good, so mostly we need regression testing there
[17:38] <mathiaz> slangasek: I don't see how we can easily do the verification there
[17:38] <mathiaz> slangasek: hm - right. So how do we do regression testing on the samba package?
[17:39] <slangasek> mathiaz: installing it as a domain controller and shaking it? :)
[17:39] <mathiaz> slangasek: what's the timeline for these verification tests to be done?
[17:40] <slangasek> mathiaz: we need to have them all wrapped up in the next week
[17:41] <mathiaz> slangasek: for the openldap bug 305264, I wrote up the test case and did the upload
[17:41] <ubottu> Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [High,Fix committed] https://launchpad.net/bugs/305264
[17:42] <mathiaz> slangasek: I thought that someone else was supposed to do the verification
[17:42] <slangasek> yes
[17:42] <mathiaz> slangasek: because it works in my use cases
[17:42] <MacSlow> Why is there no ubuntu branch for gnome-power-manager? (like for lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu)
[17:42] <slangasek> mathiaz: I asked dendrobates if the server team could help with verifications on these; I didn't tell him to pick on you specifically :-)
[17:43] <mathiaz> slangasek: Oh I don't imply that. I'm looking at the bugs to see the potential work
[17:44] <mathiaz> slangasek: IIUC verification requires both checking that the bug is fixed *and* that there isn't any regression
[17:44] <slangasek> correct
[17:44] <mathiaz> slangasek: we've got no plans to cover the latter for the samba, redhat-cluster suite and openldap packages
[17:45] <slangasek> I'm not willing to assume that there's a pool of people using hardy-proposed that will see these packages and notice breakage, so regression testing has to be explicit
[17:45] <slangasek> not necessarily /deep/, but explicit
[17:45] <mathiaz> slangasek: agreed.
[17:45] <slangasek> for openldap, the security team's test suite might be appropriate?
[17:46] <mathiaz> slangasek: right - that's an option
[17:46] <mathiaz> slangasek: and there is also the upstream test suite that is rather good for openldap
[17:47]  * slangasek nods
[17:47] <mathiaz> slangasek: for samba and redhat-cluster-suite we've got nothing AFAICT
[17:48] <mathiaz> slangasek: so that means more time is needed to get the bugs verified
[17:48] <mathiaz> slangasek: s/bug/upload/
[17:49] <slangasek> yes; unfortunately these have each been lingering for over a month already, we need *somebody* to pick up the verification
[17:50] <slangasek> sbeattie: ^^ do you have some bandwidth to set up a verification of the samba hardy SRU bugfix?  probably requires a bit more committment than the average hug dayer will want to make
[17:51] <sbeattie> slangasek: yeah.
[17:52] <mathiaz> sbeattie: I can outline what needs to be done in terms of regression testing in the bug
[17:52] <mathiaz> sbeattie: it's probably a day of work to get everything setup correctly
[17:52] <sbeattie> mathiaz: please do! my samba knowledge is somewhat shallow.
[17:55] <tseliot> superm1: I've uploaded the package here: https://launchpad.net/~albertomilone/+archive/broadcom-sta
=== thegodfather is now known as fabbione
[18:02] <mathiaz> sbeattie: I've updated the bug
[18:03] <mathiaz> sbeattie: the biggest hurdle will be to have access to a NT/200X domain
[18:03] <slangasek> mathiaz, sbeattie: Etienne should be able to get you access to one
[18:04] <mathiaz> slangasek: right
[18:04] <sbeattie> okay, thanks.
[18:04] <mathiaz> sbeattie: another solution (that I haven't had time to investigate a lot) is to use EC2
[18:05] <mathiaz> sbeattie: EC2 now has the possibility to boot windows system
[18:05] <mathiaz> sbeattie: last time I tried to install AD on it, it failed though.
[18:07] <sbeattie> I do have access to a win2k instance locally, but have never set it up as a domain controller.
[18:08] <mathiaz> sbeattie: seems that it may be a good opportunity to dive into that :)
[18:12] <superm1> tseliot, great, and it looks like that was successful on all 3 arch's too
[18:13] <tseliot> superm1: ok, let me push the fix
[18:16] <tseliot> superm1: ok, the fix is in revision 15. Can you check my changes, please (my eyes are very tired)?
[18:17] <superm1> tseliot, yeah those look sane to me
[18:17] <superm1> tseliot, bump the changelog entry up for the fix, and i can sponsor that in
[18:18] <tseliot> superm1: sure
[18:21] <tseliot> superm1: ok, done
[18:51] <cr3> pitti: if I have a crash file under /var/crash, how can I submit it to launchpad from the command line?
[18:56] <slangasek> cr3: apport-cli -c /path/to/crash
[19:00] <cr3> slangasek: darn, doesn't support http_proxy environment variable :(
[19:01] <ogra_> cr3, file a bug !!
[19:05] <tgpraveen1> are there any plans for LIRC integration with notify-osd
[19:05] <tgpraveen1> if I click play on my remote then play notification could come
[19:05] <cr3> ogra_: thanks for the reminder, I added my 2c to the existing bug #370924
[19:05] <ubottu> Launchpad bug 370924 in apport "apport doesn't work behind a proxy" [Undecided,Confirmed] https://launchpad.net/bugs/370924
[19:05] <ogra_> ah
[19:05] <ogra_> sorry for nagging :)
[19:06] <cr3> ogra_: all good, my reaction was actually "meh, there's probably a bug open already" or "pitti probably knows already"
[19:06] <ogra_> and he didnt fix it yet !!!
[19:06] <cr3> ogra_: see, that's how confident I am that ubuntu is being tested by everyone, but there's a problem when everyone starts expecting everyone else to have done the work of reporting :)
[19:07] <cr3> ogra_: there are probably issues with the fact apport runs as root, I'd expect it to not be as trivial as it sounds
[19:07] <ogra_> well, as we all know pitti he usually fixes the bugs a day before they are filed ;)
[19:07] <cr3> ogra_: perhaps trivial ones, but maybe he coded those bugs on purpose in the first place in order to acquire that superstar status :)
[19:09] <ogra_> haha
[19:09] <ogra_> karma fishing :)
[19:15] <mathiaz> kees: do you know how to interpret the values Sig* from /proc/pid/status ?
[19:16] <Keybuk> mathiaz: I know
[19:17] <Keybuk> mathiaz: iirc, they're just all 0 :p
[19:18] <Keybuk> actually, they might not be, the kernel might re-apply the SigQ to it
[19:18] <Keybuk> basically they're the set of pending, blocked, etc. signals for that process
[19:18] <Keybuk> SigPnd = signals pending
[19:18] <Keybuk> ShdPnd = shared signals pending
[19:18] <Keybuk> SigBlk = blocked signals (process mask)
[19:19] <Keybuk> SigIgn = ignored signals (SIG_IGN)
[19:19] <Keybuk> SigCgt = caught signals
[19:19] <Keybuk> each column is a signal
[19:19] <Keybuk> 1 if in the set, 0 if not
[19:19] <mathiaz> Keybuk: http://paste.ubuntu.com/199475/
[19:20] <mathiaz> Keybuk: these are two different mysqld_safe processes - once after an apt-get install and another after a reboot of the system
[19:20] <Keybuk> oh, sorry
[19:20] <Keybuk> it's hex
[19:22] <Keybuk> what are you looking for?
[19:22] <mathiaz> Keybuk: whether SIGHUP is ignored
[19:23] <mathiaz> Keybuk: I'm tracking down bug 326768
[19:23] <ubottu> Launchpad bug 326768 in mysql-dfsg-5.0 "mysqld_safe thinks mysqld has crashed when it hasn't" [High,In progress] https://launchpad.net/bugs/326768
[19:23] <mathiaz> Keybuk: and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527623
[19:23] <Keybuk> mathiaz: in the second one, it looks like it
[19:23] <ubottu> Debian bug 527623 in mysql-server-5.0 "mysql-server-5.0: 38_scripts__mysqld_safe.sh__signals.dpatch is inherently" [Important,Open]
[19:23] <mathiaz> Keybuk: so it seems that after apt-get install is run, SIGHUP is ignored by shell scripts
[19:24] <Keybuk> possibly
[19:24] <Keybuk> if apt sets SIGHUP to SIG_IGN
[19:24] <mathiaz> Keybuk: ie shell scripts (mysqld_safe in that case, started by mysql init script) ignore SIGHUP after the mysql-server package is installed
[19:24] <Keybuk> then that'll be passed on to dpkg
[19:24] <Keybuk> which will be passed on to the maintainer scripts
[19:24] <Keybuk> which will start the service
[19:25] <Keybuk> which, if it doesn't change it, will also be SIG_IGN
[19:25] <Keybuk> we should write a replacement init daemon that has a proper "start" command to avoid this kind of thing ;)
[19:25] <Keybuk> one assumes though that mysqld sets SIGHUP to something else itself anyway?
[19:26] <mathiaz> Keybuk: yes - mysqld installs its own handler
[19:26] <mathiaz> Keybuk: however the init script uses mysqld_safe, which is a wrapper around mysqld that makes sure to restart mysqld if it crashes
[19:26] <Keybuk> ah, and mysqld_safe therefore doesn't TERM on SIGHUP ?
[19:27] <mathiaz> Keybuk: mysqld_safe being a /bin/sh script
[19:27] <Keybuk> ./apt-pkg/deb/dpkgpm.cc:      // ignore SIGHUP as well (debian #463030)
[19:27] <Keybuk> ./apt-pkg/deb/dpkgpm.cc:      sighandler_t old_SIGHUP = signal(SIGHUP,SIG_IGN);
[19:27] <ubottu> Debian bug 463030 in apt "apt >=0.7.7 break menu update mechanism" [Important,Closed] http://bugs.debian.org/463030
[19:27] <Keybuk> ... fail
[19:27] <mathiaz> Keybuk: nope - SIGHUP is trapped so that a refresh command is send to mysqld via mysqladmin
[19:27] <Keybuk> it's amazing how many people forget that your signal mask and disposition are passed onto your children
[19:27] <Keybuk> mathiaz: the shell script uses trap?
[19:28] <mathiaz> Keybuk: yes - http://paste.ubuntu.com/199481/
[19:28] <Keybuk> mathiaz: that should set a signal-handler in the shell, surely?
[19:29] <mathiaz> Keybuk: hm - apparently not
[19:29] <mathiaz> Keybuk: if I send a killall -HUP mysqld_safe the refresh command is not sent to mysqld
[19:29] <mathiaz> Keybuk: just after the package installation
[19:29] <mathiaz> Keybuk: however it does work correctly after the system is rebooted (for ex)
[19:29] <Keybuk> dash src/trap.c looks like it sets sigaction() for a trap
[19:30] <Keybuk> are you sure that killall is actually sending the signal to the process?
[19:30] <Keybuk> killall sometimes likes to pretend it can't see things
[19:31] <mathiaz> Keybuk: well how can I make sure of that?
[19:31] <Keybuk> strace
[19:31]  * mathiaz tries
[19:31] <Keybuk> though I admit it's suspicious that it looks like it's ignored ;)
[19:33] <mathiaz> Keybuk: hm - using "sudo kill -HUP $(pgrep mysqld_safe)" gives the same result
[19:35] <mathiaz> Keybuk: and stracing the kill command gives http://paste.ubuntu.com/199487/
[19:35] <mathiaz> Keybuk: which seem like kill sent the SIGHUP command to the correct process
[19:36] <Keybuk> yeah
[19:36] <mathiaz> Keybuk: so the last comment on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527623 may be useful
[19:36] <ubottu> Debian bug 527623 in mysql-server-5.0 "mysql-server-5.0: 38_scripts__mysqld_safe.sh__signals.dpatch is inherently" [Important,Open]
[19:37] <mathiaz> Keybuk: especially this paragraph: http://paste.ubuntu.com/199490/
[19:37] <Keybuk> right, I was just reading through the trap source code for dash
[19:38] <Keybuk>                 if (act.sa_handler == SIG_IGN) {
[19:38] <Keybuk>                         if (mflag && (signo == SIGTSTP ||
[19:38] <Keybuk>                              signo == SIGTTIN || signo == SIGTTOU)) {
[19:38] <Keybuk>                                 tsig = S_IGN;   /* don't hard ignore these */
[19:38] <Keybuk>                         } else
[19:38] <Keybuk>                                 tsig = S_HARD_IGN;
[19:38] <Keybuk>                 } else {
[19:38] <Keybuk>                         tsig = S_RESET; /* force to be set */
[19:38] <Keybuk>                 }
[19:38] <Keybuk>         }
[19:38] <Keybuk>         if (tsig == S_HARD_IGN || tsig == action)
[19:38] <Keybuk>                 return;
[19:38] <Keybuk> so yeah, it looks right
[19:38] <Keybuk> apt sets SIGHUP to be ignored
[19:39] <Keybuk> fails to run dpkg in a clean environment
[19:39] <Keybuk> dpkg passes on the ignored SIGHUP to its maintainer scripts
[19:39] <Keybuk> its maintainer scripts run the initscripts
[19:39] <Keybuk> so initscripts are run in an inconsistent environment
[19:39] <mathiaz> Keybuk: only SIGHUP? or are there other signals ignored too?
[19:39] <Keybuk> SIGQUIT and SIGINT too
[19:40] <Keybuk> though those are ignored in your top as well
[19:41] <mathiaz> Keybuk: right - this a little bit more worrysome: There is also a trap for INT QUIT and TERM to send a shutdown command to mysqld
[19:41] <mathiaz> Keybuk: that means that after a package install, mysqld would not be shutdown properly
[19:49] <mathiaz> Keybuk: could upstart be used in karmic to replace mysqld_safe (wrapper script around mysqld)?
=== thegodfather is now known as fabbione
[20:12] <EvanCarroll> wow.
[21:03] <kees> mathiaz: is it not documented upstream?  let me go check
[21:04] <kees> mathiaz: oh, nm, Keybuk gotcha
[21:06] <Keybuk> mathiaz: TERM doesn't look like it's ignored
[21:06] <Keybuk> mathiaz: and yes, Upstart should be able to wrap mysqld_safe
[21:07] <Keybuk> just as soon as I get 0.10 out the door
[21:18] <mathiaz> Keybuk: I could upstart replace mysqld_safe (which is a wrapper around mysqld)?
[22:15] <pitti> cr3: http_proxy> iz python urllib bug (and well-known)
[22:15]  * pitti -> off again
[22:15] <cr3> pitti: I knew there was a good reason, you might like to add that to the bug so that people know
=== Quintasan_ is now known as Quintasan
[22:26] <mathiaz> slangasek: I've updated bug 326768
[22:26] <ubottu> Launchpad bug 326768 in mysql-dfsg-5.0 "mysqld_safe thinks mysqld has crashed when it hasn't" [Undecided,Incomplete] https://launchpad.net/bugs/326768
[22:26] <mathiaz> slangasek: I've found a regression if bash is used as the default shell (/bin/sh)
=== kirkland` is now known as kirkland
[22:37] <c_korn> when will the next daily build be available?
[22:39] <mathiaz> bdmurray: hey - is there a way in LP bugs to get all the bugs that have a reply made after *my* last comment?
[22:39] <mathiaz> bdmurray: I've got ~20 bugs in mysql where I have asked the same feedback to reporter and would like to go through the ones where updates have been posted
[22:40] <bdmurray> mathiaz: maybe incomplete w/ response sort by date last updated?
[22:41] <mathiaz> bdmurray: w/ == without?
[22:41] <bdmurray> mathiaz: otherwise some python-launchpad-bugs magic should do it
[22:41] <bdmurray> mathiaz: w/ == with
=== rickspencer3-afk is now known as rickspencer3
[22:43] <mathiaz> bdmurray: thanks - seems like it gives me the list I want :)
[22:43] <bdmurray> mathiaz: this url should do it https://bugs.edge.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bugs?field.searchtext=&orderby=-date_last_updated&search=Search&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=mathiaz&field.subscriber=&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&fi
[23:05] <slangasek> mathiaz: hmm - why would anyone do that? :)
[23:06] <slangasek> "dash is too fast for me, let's use bash instead" :)
[23:11] <mathiaz> slangasek: well - apparently some people do that - there was a similar bug in openldap IIRC
[23:11] <mathiaz> slangasek: hm - well - I'm not sure anymore about openldap
[23:12] <slangasek> well, it's a bug certainly if the scripts aren't POSIX-clean, but I'd treat that as rather low-priority
[23:12] <EvanCarroll> god these automated bug reports are overhwhelming
[23:12] <EvanCarroll> 95% of them are dupes
[23:12] <EvanCarroll> one program crashes and it affects 5 things, you get 5 bug reports, he does it five other times you get 25 total bug reports
[23:12] <EvanCarroll> from the same person
[23:39] <dtchen> TheMuso: finally getting traction with fedora folks in cooperating on sound stack issues :)
[23:40] <Viper550> hey
[23:42] <Viper550> http://hacktolive.org/wiki/App_Runner should be integrated somehow
[23:42] <dtchen> Viper550: discussion already started; not sure if it's public aside from logs of this channel
=== rickspencer3 is now known as rickspencer3-afk