[01:13] <dtchen> hyperair: jaunty? karmic? lucid? what hardware?
[01:48] <hyperair> dtchen: jaunty. i don't actually have a usb headset to try it out with, but all the problems i've heard of audio delay with skype seem to stem from pulseadio + usb headset.
[01:59] <ScottK> maxb: Do I have a debdiff from you?
[02:01] <ScottK> I see it now.
[02:01] <ScottK> I thought I'd subscribed to the bug, but I guess I hadn't.
[02:03] <jdong> kees: *grins* A friend and I are actually making good headway on a clone of sandbox exec using AppArmor, as we previously discussed
[02:03] <jdong> (i.e. allowing users to voluntarily opt into AA restrictions)
[02:23] <kees> jdong: Nice!
[02:24] <kees> jdong: I was playing a little bit with lxc to a similar end.  It was fun having bash be pid 1.  :)
[02:24] <jdong> yeah, that sounds cool :)
[02:36] <ion> kees: Boot Linux with init=/bin/bash and you’ll have bash as pid 1. ;-)
[02:38] <kees> ion: well, yeah.  :P
[02:38] <kees> ion: I guess I meant it was fun to have two pid 1s.  :)
[02:40] <ion> :-)
[04:25] <smoser> anyone able to help... i know its late.
[04:25] <smoser> i have a known key that i want to feed to : apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ${key}
[04:25] <smoser> i'm trying to automate something and that is timing out.
[04:26] <smoser> it could be timing out because the server is just slow (as I've seen before) or because networking is blocking me.
[04:26] <smoser> either way, i know the 'key' that i want to get, and can pre-get it ... i just want the same effect
[04:27] <smoser> anyone know how i can do the same thing that apt-key does above without the network operation /
[04:28] <wgrant> smoser: sudo apt-key add $somekeyfile
[04:28] <smoser> righ..i just was realizing that...
[04:28] <smoser> how do i get 'somekeyfile' ?
[04:30] <smoser> sudo apt-key export key
[04:31] <slangasek> GNUPGHOME=./mytmpdir gpg --keyserver keyserver.ubuntu.com --recv-keys ${key}; GNUPGHOME=./mytmpdir gpg --export ${key} --output $somkeyfile
[04:32] <smoser> thank you slangasek wgrant .
[06:30] <dtchen> hyperair: certainly possible, though lucid's is better, and I haven't been able to reproduce the symptom in karmic or lucid
[07:49] <hyperair> dtchen: i see. it'll be good to request details about the hardware they're using. there appears to be a lot of hate for pulseaudio
[09:57] <pecisk> hi people, what kernel Lucid will have in the end? It is already decided?
[09:57] <pecisk> I mean what version
[10:11] <tjaalton> pecisk: 2.6.32
[10:14] <geser> tkamppeter: re bug 495548: it's usually enough to subscribe ~ubuntu-archive to such bugs (which I've done), no need to assign it to them
[10:18] <pecisk> tjaalton, I just interested will nouveau driver will be used as geforce default 2d driver in Lucid? Or it is just too risky yet?
[10:21] <tjaalton> pecisk: it will be tried, and after alpha2 decided if it's go/no-go
[10:22] <pecisk> cool :)
[10:22] <pecisk> tjaalton, thanks for info
[10:23] <ogra> hrm
[10:23] <ogra> is pybootchartgui supposed to work in lucid atm ?
[10:24] <tjaalton> pecisk: https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-driver-selection-for-nvidia-hardware
[10:36] <gnomefreak> tjaalton: the nvidia discussion above related to bug 495779? is there a work around atm?
[10:55] <tjaalton> gnomefreak: no. it needs a newer version built against the current xserver-xorg-dev
[10:55] <gnomefreak> tjaalton: ah ok thanks
[12:04] <Mamarok> hi all
[12:05] <Mamarok> about this bug: https://bugs.edge.launchpad.net/ubuntu/+source/eglibc/+bug/425723, is there a chance to get a newer glibc version in Karmic soon? It causes quite a few problems in KDE apps
[12:05] <apachelogger> doko_: ^
[12:05] <Mamarok> thx apachelogger:)
[12:06] <Tm_T> Mamarok: brrrh, that's why I have kdelibs(?) with small patch
[12:06] <Tm_T> using malloc 2 instead of 3 (IIRC)
[12:07] <apachelogger> doko_: Mamarok is poking around for weeks now and preventing me from doing useful things by making me read duplicates of that particular bug, so pretty please do something about it :)
[12:07] <Mamarok> Tm_T: well, it's not in Karmic AFAICS, don't expect users to apply patches
[12:07] <Tm_T> Mamarok: I know, just saying that this isn't new issue at all
[12:07] <Mamarok> all other ditstros have either patched their glibc or use a newer version, I only get reports from Ubuntu users now
[12:07] <Mamarok> distros*
[12:08] <Tm_T> so yes, please fix (:)
[12:08] <Mamarok> see also http://www.purinchu.net/wp/2009/11/16/malloc_check_-crashes/
[12:25] <cjwatson> Mamarok: I think we should - I've targeted the bug for karmic and will try to remember to follow up with whoever's available on Monday
[12:25] <Mamarok> cjwatson: thanks a lot :)
[12:25] <cjwatson> doesn't help that sourceware.org is down from here right now, but I've got the general idea
[12:27] <apachelogger> cjwatson: thanks ... google cache is your friend http://www.google.com/search?hl=en&q=cache:http://sourceware.org/bugzilla/show_bug.cgi%3Fid%3D10282
[12:28] <apachelogger> not that it helps with the patch, but with information :)
[12:29] <cjwatson> apachelogger: yes, already been there
[12:29] <apachelogger> k :)
[12:34] <David-T> cjwatson: hi. you might want to look at bug #493772 at some point (as i think it was introduced by your latest change to mdadm)
[12:56] <oussama> hi guys
[12:57] <oussama> how to upload a package in the universe or multiverse
[13:27] <maxb> Could someone (who is a core-dev) push lp:~maxb/ubuntu/lucid/subversion/merge into lp:ubuntu/subversion? It's already been uploaded to the archive, but bzr hasn't been updated accordingly. Thanks.
[13:28] <maxb> I've committed a final revision to the branch fixing it up to exactly what was uploaded, and have `bzr mark-uploaded` it
[13:35] <Laibsch> ArneGoetje: I have a question for you if I may.  I see you maintain scim upstream development is dead.  Yet, when I look at upstream svn I see lots of activity.  Do you know more than me?  Please explain.  I'm not questioning the scim->ibus move.  I'm just curious.
[14:05] <ArneGoetje> Laibsch: scim has some serious design issues which noone is working on.
[14:07] <Laibsch> that may be true, but it's different from "upstream development has stopped".  It's a quality issue.
[14:10] <ArneGoetje> Laibsch: there has been no progress upstream to fix those long standing issues.
[14:10] <Laibsch> I don't dispute that
[14:10] <Laibsch> Do you have an example?
[14:11] <ArneGoetje> Laibsch: development upstream is not going forward, they only maintain the status quo
[14:12] <ArneGoetje> Laibsch: for example teh Locale issue. Scim has been designed for zh_* and en_US locales in the first place. If you use any other locale than that, you need to hack the scim config file to get scim working.
[14:13] <ArneGoetje> Laibsch: instead, scim could have just accepted any UTF-8 locale by default.
[14:14] <Laibsch> I'm not familiar with "the locale issue".  Do you have a bug number?  I'm surprised to hear that scim is China-centric.  That was a mild concern I had with ibus, given that both devs are Chinese.
[14:16] <ArneGoetje> Laibsch: no, I don't have a bug number. But it's common knowledge with Chinese users and IM developers. IBus does the right thing. It accepts any UTF-8 locale by default.
[14:17] <Laibsch> good
[14:17] <ArneGoetje> Laibsch: IBus has been developed because of the design issues SCIM has.
[14:18] <Laibsch> I never questioned the many problems present in scim.  And as mentioned initially am not questioning the move from scim to ibus.  But I do think "scim upstream is dead" is not a correct statement.  If you disagree, that's something I can't change.
[14:19] <Laibsch> scim svn has activity and I think there is an influx of devs, too
[14:19] <Laibsch> But I'm not watching very closely
[14:20] <cjwatson> David-T: doesn't seem to have anything to do with the source changes I made.
[14:21] <cjwatson> David-T: I think it would be more correct to figure out why the rules file got renamed; my suspicion is that it was an accident due perhaps to a change in dh_installudev, and the old name was better
[14:21] <ArneGoetje> Laibsch: svn activity has nothing to do with progress being made to fix those long standing issues. As far as I can tell from the scim-devel mailing list, most activity is about adding new input methods.
[14:22] <Laibsch> ArneGoetje: "scim is not progressing in the direction we see as necessary" -> OK
[14:22] <Laibsch> "scim upstream development is dead" -> factually wrong IMHO
[14:23] <Laibsch> that is what I'm saying
[14:23] <Laibsch> but we may agree to disagree
[14:26] <cjwatson> David-T: see the changelog for debhelper 7.4.2
[14:29] <cjwatson> David-T: I'll sort it out, anyway; thanks for the note
[14:32] <joaopinto> any ideas on what could cause an ureadahead-other main process (18103) terminated with status 4 endless loop ?
[14:33] <joaopinto> I hate cryptic log messages
[14:33] <David-T> cjwatson: ah, that makes more sense. thanks.
[14:34] <joaopinto> Dec 12 14:16:25 pt001424-laptop init: ureadahead-other main process (18121) terminated with status 4
[14:34] <joaopinto> is this an upstart message ?
[14:35] <cjwatson> yes
[14:36] <cjwatson> it's harmless anyway
[14:36] <cjwatson> # Don't treat a normal exit after reading finishes as a failure, and
[14:36] <cjwatson> # don't treat a missing pack file as an error either
[14:36] <cjwatson> normal exit 0 4
[14:36] <cjwatson> (/etc/init/ureadahead-other.conf)
[14:37] <joaopinto> cjwatson, on my case it's associated with another problem, udev and friends using excessive cpu
[14:37] <cjwatson> I'm not volunteering to debug it, I just answered your question
[14:37] <joaopinto> restarting udev fixes both, the cpu and stops the message
[14:38] <joaopinto> nothing is harmless when it's endelessly logged :)
[14:39] <cjwatson> I shouldn't have said anything, I suppose :P
[14:39] <cjwatson> you should file a bug on ureadahead
[14:39] <cjwatson> David-T: fixed
[14:41] <joaopinto> the symptom is the same described on bug 379780 , except that no one noted ureadahead  messages
[14:43] <cjwatson> that symptom is very vague so it doesn't mean it's the same bug
[14:43] <joaopinto> ok, I will file a bug for ureadahead
[14:44] <ArneGoetje> Laibsch: well, if it makes you happy, I can rephrase the statement to "scim upstream is not progressing in fixing long standing software design issues"
[14:45] <joaopinto> hum, probably I should comment the ntfs partition from nfstab, it's causing the already reported mountall loop from the hibernate status, I guess it could be related to the later sreadahead issues
[14:46] <joaopinto> hum, apport reports an error when trying to do the PackDump, I guess it requires root
[15:06] <directhex> is the plan for ff3.5 or ff3.6 in lucid?
[15:07] <joaopinto> uff, found that both the cpu & errror msg are related to the mountall endless loop bug
[15:07] <joaopinto> bug open, bug close
[15:13] <jdstrand> slangasek, james_w, Riddell, cjwatson, kirkland, StevenK, al-maisan: fyi, I got 'sync-source.py -a' to work again by identifying source format 3.0 packages and adding them to /srv/launchpad.net/dak/sync-blacklist.txt (temporarily). When bug #293106 is fixed, we need to remove these from the blacklist.
[15:13] <jdstrand> slangasek, james_w, Riddell, cjwatson, kirkland, StevenK, al-maisan: some 154 packages just sync'd \o/
[15:15] <jdstrand> slangasek, james_w, Riddell, cjwatson, kirkland, StevenK, al-maisan: see r214 for the update to the blacklist. of course, something else could float into testing that breaks it again, but it should be easy enough to see and add to the temporary blacklist
[15:15] <joaopinto> When I plugin a vodafone pcmcia card I get 4 ttyUSB devices, network manager randomly connects, I have found that it only connects when it selects /dev/ttyUSB0, what is responsible to identify the modem device, networkmanager or modemmanager ?
[15:15] <jdstrand> geser: fyi ^
[15:15] <joaopinto> I may have the bug reported into the wrong package
[15:16] <Riddell> jdstrand: great
[15:16] <Riddell> that'll be fun for whoever has an archive admin day next :)
[15:17] <jdstrand> heh
[15:35] <dtchen> hyperair: yes, details about lower parts of the audio are always required for debugging. Misplaced hate is often seen.
[15:38]  * geser hugs jdstrand
[15:45] <Tm_T> packages.ubuntu.com is not available today?
[16:03] <jpds> Tm_T: It likes doing that on weekends.
[16:04] <Tm_T> ah, didn't know, thanks
[16:07] <jpds> jdstrand: I think the branch which adds v3 support to soyuz landed in devel today, and should hopefully be available in production from the 16th (I believe).
[16:10] <jpds> jdstrand: Reading http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/10048 that is.
[16:23] <geser> as far as I know there are final test runs for the format 3.0 branch scheduled for the beginning of next week
[16:54] <geser> could a core-dev please give-back: indicator-applet indicator-messages indicator-session. Thanks
[16:59] <geser> please also give-back: nautilus-sento libpam-mount. Thanks.
[17:58] <mmoya> any news on unavailability of packages.ubuntu.com ?
[18:00] <geser> it's weekend, so most people aren't available
[18:17] <oussama> hi guys
[18:17] <oussama> how to upload a package ??
[18:17] <oussama> in the universe or multicerse
[18:17] <oussama> multiverse
[18:17] <oussama> ???
[19:03] <oussama> !package
[19:28] <slangasek> jdstrand: well, it certainly will break again; if you check the blacklist file, you'll find other blacklisted v3 packages, including some 110 of them at the top of the file
[19:42] <oussama> what is dfsg
[19:42] <oussama> !dfsg
[19:43] <azeem> oussama: you asked that already in #ubuntu-motu
[19:43] <oussama> i want just more explications
[19:43] <azeem> then ask more specific questions, in #ubuntu-motu
[19:53] <diwic> I'm packaging a small utility which contains a .py file and a wrapper script. Both are installed into /usr/bin. Lintian complains about the .py file having .py extension in /usr/bin. Should I move it to install somewhere else?
[19:54] <geser> is the file expected to be used/called by a user?
[19:55] <diwic> geser: difficult to know really. At least 99% of the cases would be calls to the wrapper script, which is the only one to have a man page.
[19:57] <geser> if it's not expected to be used by the user then it shouldn't be in /usr/bin but instead something like /usr/share/$pkgname/
[19:58] <diwic> And modify the wrapper script to reflect that
[19:58] <geser> yes
[20:00] <diwic> thanks!
[20:08] <PovAddict> http://packages.ubuntu.com/ <- down?
[20:09] <diwic> PovAddict: confirmed
[20:10] <PovAddict> I'm on debian, I was trying to help someone with ubuntu but couldn't check if a package name on ubuntu was what I expected it to be...
[20:11] <diwic> PovAddict: what's the package name and Ubuntu version?
[20:11] <PovAddict> don't worry, that's solved :)
[20:11] <diwic> ok
[20:15] <oussama> what does patch do ?
[20:15] <dtchen> ARGH
[20:16] <dtchen> dpkg-buildpackage is clobbering CFLAGS
[20:16] <dtchen> this completely breaks alsa-lib :(
[20:16] <dtchen> bad! dpkg-buildpackage: set CFLAGS to default value: -g -O2
[20:17] <dtchen> now I get to hack upstream configure*
[20:17] <Ryan52> dtchen: change CFLAGS in debian/rules.
[20:17] <dtchen> Ryan52: we already do.
[20:17] <dtchen> it gets RESET
[20:17] <Ryan52> by what?
[20:17] <Ryan52> dpkg-buildpackage can't change the CFLAGS you set in debian/rules..
[20:18] <Ryan52> it just sets the default.
[20:22] <dtchen> this had better not be another local schroot problem :(
[20:43] <dtchen> bah, it was libtoolise screwage
[20:53] <wgrant> geser: It landed earlier than I expected. It is definitely in for the release.
[20:55] <evolio> hello, does anyone know if there is a proposal to put graphical volume monitors in sound properties
[20:56] <dtchen> evolio: check with upstream gnome-media
[20:57] <jdstrand> slangasek: sure-- moved the ones I added to the top of the file. I didn't notice them
[20:58] <tormod> evolio, there are already for inputs, very handy
[21:00] <jdstrand> slangasek: we're now up to 160!
[21:00] <slangasek> yeah
[21:00]  * jdstrand is looking forward to that bug being fixed
[21:00] <slangasek> the LP release this Wednesday is due to fix it
[21:00]  * jdstrand nods
[21:00] <wgrant> It has landed, so the LP code will be there.
[21:01] <wgrant> But I'm not sure about the buildds, and I suspect your sync scripts will need some small fixes (they're not part of LP, so I can't test them).
[21:02] <slangasek> the sync scripts are part of LP
[21:02] <slangasek> scripts/ftpmaster-tools/sync-source.py
[21:02] <wgrant> sync-source.py itself is.
[21:02] <wgrant> But the rest of it is not.
[21:02] <slangasek> that's the script that's breaking :)
[21:03] <slangasek> if you mean mass-sync.py, that doesn't look at the source package, it just hands off to sync-source.py
[21:04] <wgrant> I know, and that will be fixed once cocoplum's dpkg is upgraded. But the flush scripts do filename globbing of some variety, and last I checked it didn't do .bz2.
[21:04] <slangasek> ah; it does now
[21:05] <wgrant> OK. So hopefully it won't break like that.
[22:54] <joaopinto> anyone experienced with NM troubleshooting and editing 10-modem.fdi ?
[22:56] <cyphermox> joaopinto, NM troubleshooting, a little.. what kind of trouble?
[22:57] <joaopinto> cyphermox, with Vodafone 3G PCMCIA card I can only randomly connect
[22:57] <joaopinto> I have found that NM is using a random device from the 4 advertised ttyUSB ports
[22:57] <cyphermox> never the same?
[22:58] <joaopinto> well, maybe it's sequential, but yes, not the same
[22:58] <joaopinto> I have reported it, bug 434275
[22:59] <joaopinto> looking at lshal, only the ttyUSB0 device advertises the "modem" capability
[23:00] <cyphermox> ok
[23:00] <joaopinto> now I just need to know if there is a way to define that the "modem" capable device should be used, I guess this would be defined at 10-modem.fdi
[23:00] <joaopinto> or, it's a NM bug, and it should prefer the "modem" device when available
[23:16] <cyphermox> joaopinto, trying to find out what it is now :)