| jcastro | anyone know anything about libtheora? Seems we just get it from debian | 00:11 |
|---|---|---|
| slangasek | jcastro: is there more to know than "it's the lib that implements the codec"? | 00:18 |
| 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:20 |
| 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:21 |
| 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:22 |
| slangasek | that's the 1.1 branch, then? | 00:23 |
| jcastro | slangasek: that would be the alpha one I am referring to | 00:23 |
| billybigrigger | anyone know when the gtk2.0 problems will be sorted? | 00:58 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| 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:09 |
| slangasek | yes, you should be able to use apport-cli -c /var/crash/crashfile to pick it up. | 01:10 |
| DreadKnight | i'm running kubuntu.. recently pidgin doesn't connects to my yahoo account... | 01:37 |
| 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:38 |
| 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 | 01:39 |
| === Snova_ is now known as Snova | ||
| === lex79 is now known as lex79_ | ||
| === lex79_ is now known as lex79 | ||
| === rgreening_ is now known as rgreening | ||
| Syrius | hello | 05:59 |
| Syrius | can you ask questions in here ? | 05:59 |
| tgpraveen | Syrius: develop related ques yes | 05:59 |
| Syrius | okay cool tgpraveen | 06:02 |
| Syrius | I have newbie questions tgpraveen | 06:02 |
| Syrius | about pbuilder | 06:02 |
| Syrius | hold on | 06:02 |
| Syrius | let me see what my question exactly is | 06:03 |
| Syrius | so once you make the debian packages you just install the ones in /var/cache/pbuild/result ? tgpraveen | 06:07 |
| Syrius | with pbuilder | 06:08 |
| tgpraveen | sorry am a noob too maybe someone else could help you here | 06:08 |
| Syrius | okay | 06:09 |
| 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:10 |
| Syrius | motu? | 06:11 |
| TheMuso | Syrius: thats the IRC channel where you will most likely get the answers to your questions. | 06:34 |
| dholbach | good morning | 06:56 |
| * nixternal hugs dholbach | 08:23 | |
| MacSlow | Greetings everyone! | 08:24 |
| 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 | 08:28 |
| === mthaddon is now known as afk | ||
| === tkamppeter_ is now known as tkamppeter | ||
| * dholbach hugs nixternal back | 08:42 | |
| hyperair | does anyone know how long it usually takes for a NEW package to get synced from Debian? | 09:11 |
| pitti | Good morning | 09:14 |
| pitti | MacSlow: seems we need to update dk-p then | 09:15 |
| 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:17 |
| MacSlow | just happy it works and I don't have to enter dependency-hell | 09:18 |
| kwah | hi all | 10:20 |
| kwah | whom may I contact with respect to tools available to create generic Ubuntu add-on CD? | 10:21 |
| === smb is now known as smb_afk | ||
| 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:13 |
| tseliot | and of course there will also be a postrm which removes the file | 11:17 |
| pitti | tseliot: that would work, since it would avoid conffiles staying around if you remove, but not purge | 11:18 |
| pitti | tseliot: but why don't you blacklist b43 in the "b44" case, and b43legacy in neither case? | 11:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:33 |
| pitti | tseliot: initramfs> yes, you need to, so that the driver isn't accidentally loaded in initramfs | 11:42 |
| tseliot | pitti: ok, thanks | 11:43 |
| === ember_ is now known as ember | ||
| 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:01 |
| 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:02 |
| tseliot | pitti: sure | 12:03 |
| 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:04 |
| 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 | 12:06 |
| === smb_afk is now known as smb | ||
| === asac_ is now known as asac | ||
| === pbn_ is now known as pbn | ||
| 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:35 |
| doko | cjwatson, pitti: this one just needs a change of directory name, or else the extra cliparts are not seen in OOo | 13:36 |
| 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:37 |
| cjwatson | doko: if you agreed with the patch in the bug report, I'm happy to sort out uploads | 13:38 |
| === ogra_ is now known as ogra | ||
| 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:41 |
| 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:42 |
| 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:43 |
| 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 | 13:44 |
| === korn_ is now known as c_korn | ||
| 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:12 |
| cprov | apw: ehe, is it also called 'janitor' ? | 14:14 |
| apw | heh ... no the failure it called me ... damn | 14:14 |
| cprov | apw: okay, ping if you need anything. | 14:15 |
| apw | cprov, thanks will do | 14:18 |
| === afk is now known as mthaddon | ||
| lool | Err I thought (hd0,1) meant sda2, not sda1; did this change with GRUB2? | 15:56 |
| cjwatson | yes, it did | 15:57 |
| === yofel_ is now known as yofel | ||
| lool | Geez how confusing | 15:57 |
| cjwatson | see http://www.gnu.org/software/grub/grub-2.en.html ("design mistakes in GRUB Legacy") | 15:57 |
| lool | Thanks | 15:58 |
| cjwatson | should mostly be using UUIDs now anyway ... | 15:58 |
| Riddell | mathiaz: will mysql 5.1 be in main for karmic or 5.0? | 16:20 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| Keybuk | also the proc connector is a firehose | 16:30 |
| Keybuk | you receive a massive number of events | 16:30 |
| 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:31 |
| 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:33 | |
| kirkland | Keybuk: so this is pretty upstarty then :-) | 16:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| Keybuk | depends whether the process is likely to come and go within IDLE | 16:39 |
| Keybuk | which is the basic race you have | 16:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| Keybuk | hey that's ok ;) | 16:47 |
| Keybuk | I've been debugging somebody's machine-that-goes-ping all day | 16:47 |
| Keybuk | it's nice to have a distraction | 16:48 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| cjwatson | we'll probably be using join for putting together debian/-only branch history with upstream | 16:57 |
| 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:58 |
| cjwatson | I guess it would be dealable with | 16:59 |
| cjwatson | we'll be on brisbane-core soon enough anyway :) | 17:00 |
| * mterry joins it up | 17:00 | |
| pitti | tseliot: great work on bcmwl! | 17:15 |
| 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:16 | |
| 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:17 |
| pitti | superm1: will do (in meeting ATM) | 17:21 |
| 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:22 |
| pitti | meh, but only on lpia :/ | 17:23 |
| 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:25 |
| 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:27 |
| pitti | superm1: it doesn't, but you can fake it by adding it as a build dep | 17:29 |
| 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 | 17:30 |
| === rickspencer3 is now known as rickspencer3-afk | ||
| tseliot | ok, thanks, I'll try it | 17:31 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| slangasek | mathiaz: we need to have them all wrapped up in the next week | 17:40 |
| 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:41 |
| 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:42 |
| mathiaz | slangasek: Oh I don't imply that. I'm looking at the bugs to see the potential work | 17:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| * slangasek nods | 17:47 | |
| mathiaz | slangasek: for samba and redhat-cluster-suite we've got nothing AFAICT | 17:47 |
| mathiaz | slangasek: so that means more time is needed to get the bugs verified | 17:48 |
| mathiaz | slangasek: s/bug/upload/ | 17:48 |
| slangasek | yes; unfortunately these have each been lingering for over a month already, we need *somebody* to pick up the verification | 17:49 |
| 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:50 |
| sbeattie | slangasek: yeah. | 17:51 |
| 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:52 |
| tseliot | superm1: I've uploaded the package here: https://launchpad.net/~albertomilone/+archive/broadcom-sta | 17:55 |
| === thegodfather is now known as fabbione | ||
| mathiaz | sbeattie: I've updated the bug | 18:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| sbeattie | I do have access to a win2k instance locally, but have never set it up as a domain controller. | 18:07 |
| mathiaz | sbeattie: seems that it may be a good opportunity to dive into that :) | 18:08 |
| superm1 | tseliot, great, and it looks like that was successful on all 3 arch's too | 18:12 |
| tseliot | superm1: ok, let me push the fix | 18:13 |
| tseliot | superm1: ok, the fix is in revision 15. Can you check my changes, please (my eyes are very tired)? | 18:16 |
| 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:17 |
| tseliot | superm1: sure | 18:18 |
| tseliot | superm1: ok, done | 18:21 |
| cr3 | pitti: if I have a crash file under /var/crash, how can I submit it to launchpad from the command line? | 18:51 |
| slangasek | cr3: apport-cli -c /path/to/crash | 18:56 |
| cr3 | slangasek: darn, doesn't support http_proxy environment variable :( | 19:00 |
| ogra_ | cr3, file a bug !! | 19:01 |
| 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:05 |
| 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:06 |
| 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:07 |
| ogra_ | haha | 19:09 |
| ogra_ | karma fishing :) | 19:09 |
| mathiaz | kees: do you know how to interpret the values Sig* from /proc/pid/status ? | 19:15 |
| Keybuk | mathiaz: I know | 19:16 |
| Keybuk | mathiaz: iirc, they're just all 0 :p | 19:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| Keybuk | what are you looking for? | 19:22 |
| mathiaz | Keybuk: whether SIGHUP is ignored | 19:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| mathiaz | Keybuk: yes - http://paste.ubuntu.com/199481/ | 19:28 |
| Keybuk | mathiaz: that should set a signal-handler in the shell, surely? | 19:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| mathiaz | Keybuk: hm - using "sudo kill -HUP $(pgrep mysqld_safe)" gives the same result | 19:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| Keybuk | though those are ignored in your top as well | 19:40 |
| 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:41 |
| mathiaz | Keybuk: could upstart be used in karmic to replace mysqld_safe (wrapper script around mysqld)? | 19:49 |
| === thegodfather is now known as fabbione | ||
| EvanCarroll | wow. | 20:12 |
| kees | mathiaz: is it not documented upstream? let me go check | 21:03 |
| kees | mathiaz: oh, nm, Keybuk gotcha | 21:04 |
| 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:06 |
| Keybuk | just as soon as I get 0.10 out the door | 21:07 |
| mathiaz | Keybuk: I could upstart replace mysqld_safe (which is a wrapper around mysqld)? | 21:18 |
| 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 | 22:15 |
| === Quintasan_ is now known as Quintasan | ||
| 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) | 22:26 |
| === kirkland` is now known as kirkland | ||
| c_korn | when will the next daily build be available? | 22:37 |
| 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:39 |
| bdmurray | mathiaz: maybe incomplete w/ response sort by date last updated? | 22:40 |
| mathiaz | bdmurray: w/ == without? | 22:41 |
| bdmurray | mathiaz: otherwise some python-launchpad-bugs magic should do it | 22:41 |
| bdmurray | mathiaz: w/ == with | 22:41 |
| === rickspencer3-afk is now known as rickspencer3 | ||
| 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 | 22:43 |
| slangasek | mathiaz: hmm - why would anyone do that? :) | 23:05 |
| slangasek | "dash is too fast for me, let's use bash instead" :) | 23:06 |
| 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:11 |
| 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:12 |
| dtchen | TheMuso: finally getting traction with fedora folks in cooperating on sound stack issues :) | 23:39 |
| Viper550 | hey | 23:40 |
| 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 | 23:42 |
| === rickspencer3 is now known as rickspencer3-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!