[02:56] <qwer> anyone here know a crapload about linux drivers?
[02:58] <qwer> I'm fairly knowledgeable, but I've a problem that no on in any other channel has been able to help me solve for about 2 weeks
[03:00] <qwer> anyway, I'll just tell the story, mysteriously ubuntu 10.04 detects the sata_mv driver properly - as well as an old slackware install cd - I've tried about a dozen recent and current distros though - and even after mod probing sata_mv -> no block devices found.......I've no idea how to continue troubleshooting - I've messed with udevadm, modprobe, etc
[03:01] <hyperair> qwer: try #ubuntu-kernel. the ones knowledgable about these things reside there, usually.
[03:01] <qwer> thanks
[03:01] <qwer> #ubuntu-kernel
[03:02] <qwer> oppppps
[04:46] <wolfe> xD is there a launchpad admin around?
[04:47] <wolfe> "me too. I would also like to unsubscribe and it won't let me. PLEASE, MAKE
[04:47] <wolfe> IT STOP!
[04:47] <wolfe> "
[04:47] <persia> wolfe: You probably have the implict bug subscription issue.  But you also probably want to ask in #launchpad
[04:48] <wolfe> I'm falling out of my seat laughing at this
[04:48] <wolfe> persia: ah okay. I haven't tried to unsubscribe yet, but I'll try too
[04:54] <emgent> persia :-)
[04:56] <twb> So I am rolling lucid live images using Debian's live-helper.
[04:56] <twb> I'm a bit puzzled by the kernel making a "ramzswap" -- why is it creating virtual swap on top of ram?
[04:57] <persia> twb: live-helper is explicitly not supported by the Ubuntu installer team (last I heard).
[04:57] <persia> You *might* get some help out of #ubuntu, but I'm unsure they would have the necessary familiarity.
[04:57] <twb> Ooooooh.  Googling finds http://code.google.com/p/compcache/, which says that ramzswap is a *compressed* virtual swap
[04:58] <twb> persia: I'm asking about the kernel, not about live-helper.
[05:00] <twb> And there's an #ubuntu-kernel, so I guess I'll bug them instead.
[05:43] <crimsun> "/usr/bin/dpkg-deb: line 53: 28311 Segmentation fault      /usr/bin/pkgstriptranslations"
[05:44] <persia> extra points!
[05:44] <crimsun> on armel, nonetheless :-/
[05:44] <crimsun> (http://launchpadlibrarian.net/39501757/buildlog_ubuntu-lucid-armel.pulseaudio_1:0.9.22~0.9.21%2Bstable-queue-32-g8478-0ubuntu10_FAILEDTOBUILD.txt.gz)
[05:46] <StevenK> Ouch
[05:47] <lifeless> isn't that python?
[05:47] <StevenK> # file /usr/bin/pkgstriptranslations
[05:47] <StevenK> /usr/bin/pkgstriptranslations: Bourne-Again shell script text executable
[05:48] <lifeless> wow
[05:48] <StevenK> Ooooh, that's even more impressive
[05:56] <TheMuso> wow that is impressive.
[05:57] <StevenK> crimsun: Throw me a link to the upload page, and I'll try and build it on the porter?
[05:58] <crimsun> StevenK: meaning https://launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10 ?
[05:59] <crimsun> (or https://edge.launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10/+build/1523932)
[05:59] <StevenK> crimsun: Yeah
[05:59] <StevenK> (The former)
[07:09] <pitti> Good morning
[07:12] <lifeless> hi pitti
[07:29] <tjaalton> nice, boot hangs after one unclean shutdown
[07:29] <tjaalton> rescue doesn't work
[07:32] <Speedy2> www.search2.net
[07:34] <tjaalton> no idea what's run after mountall?
[07:34] <tjaalton> much harder to debug with upstart..
[07:39] <lifeless> pitti: I filed a bug on lp-project-upload
[07:39] <lifeless> pitti: I'd like to move it out of ubuntu-dev-tools; its not really ubuntu related ;)
[07:39] <pitti> tjaalton: what do you see?
[07:40] <pitti> lifeless: I know, but u-d-t is a kind of catch-all place for these tools
[07:40] <lifeless> pitti: but I then rewrote it from scratch anyhow :P so perhaps just nuke it now (once my lptools patch lands)
[07:40] <lifeless> pitti: 'lptools'
[07:40] <pitti> lifeless: same is true for lp-set-dup, grab-attachments, lp-shell, and whatnot
[07:40] <tjaalton> pitti: /usr being mounted
[07:40] <lifeless> pitti: for some of them, I totally agree
[07:41] <tjaalton> this worked last night when I upgraded the box
[07:41] <pitti> tjaalton: so it's not the plymouth hang yet?
[07:41] <tjaalton> but the power button didn't make acpid to shut it down (though acpi_listen showed it sending the signal), so I pulled the plug
[07:41] <tjaalton> pitti: no, it's a server install
[07:42] <tjaalton> I've disabled ureadahead and plymouth
[07:42] <tjaalton> by moving the jobs away
[07:49] <dholbach> good morning
[07:54] <tjaalton> even if I don't have splash on the kernel cmdline it loads some framebuffer module (probably vga16fb), which makes debugging even harder
[07:54] <tjaalton> since the screen is reset and previous messages are gone
[07:55] <tjaalton> so is there a way to disable that from grub?
[07:55] <tjaalton> hmm, nofb maybe
[07:56] <tjaalton> nope
[08:32] <tjaalton> oh well, got to reinstall it then..
[09:00] <poolie> pitti, hi
[09:01] <pitti> hey poolie, how are you?
[09:01] <poolie> good
[09:01] <poolie> lifeless pointed me to your lp-shell command
[09:01] <poolie> i would like to show you bugclient in lp:hydrazine
[09:01] <poolie> it gives you a specific command line interface to lp
[09:01] <poolie> rather than a python shell
[09:02] <poolie> eg you can say 'bug 123' 'triage +tags +easy confirmed medium'
[09:02] <pitti> poolie: oh, that's useful
[09:02] <poolie> i find it pretty nice
[09:02] <pitti> poolie: it seems to have quite a different purpose than lp-shell, but useful for mass bug operations
[09:02] <poolie> yes, that's true
[09:03] <poolie> it doesn't really support bulk operations atm
[09:03] <poolie> but it's pretty quick for single operations
[09:03] <lifeless> pitti: so to continue the prior conversation; how do you feel about us moving the non distro stuff to the lptools project; build an upstream there, rather than having them in ubuntu-dev-tools that is a bit more restricted for getting developers
[09:03] <lifeless> this is related to poolies hydrazine project too
[09:03]  * persia thinks this is a good idea
[09:04] <pitti> lifeless: sounds fine to me
[09:04] <pitti> u-d-tools could even recommends: lptools
[09:04] <pitti> to have the same effect
[09:04] <persia> And make the transition near-invisible for most developers.
[09:04] <lifeless> I'm going to have to apply sanity-sticks to get that project to have more committers in the short term; once thats done I'll submit a merge proposal to clear things up
[09:05] <lifeless> we do have different licences on the current code, but the sasme (C) holder. for hilarity.
[09:14] <ogra> seb128, poke ... with the last gtk upload my system started to misbehave massively, i had to downgrade libgtk2.0-2 ... did you hear complaints from anyone else ?
[09:14] <seb128> define misbehave
[09:14] <seb128> "it doesn't work"?
[09:15] <ogra> seb128, like X taking 100% CPU, evo locking up the machine, widgets in xchat's chat window start to flicker heavily, gnome-terminal flikers a lot
[09:15] <seb128> bug #523949
[09:15]  * ogra checks
[09:15] <seb128> for the cpu issue, I'm about to upload an improved version
[09:16] <seb128> dunno about the flickering
[09:16] <ogra> in xchat the separator between nicks and text (that little vertical line) gets random flickering dots ... looks like an old movie :)
[09:17] <ogra> i know jdub had similar issues ... but that bug seems to describe it, i'll try the upgrade
[09:56] <poolie> pitti, lifeless: so having one client set for launchpad is better than having many fractional-assed ones
[09:56] <pitti> poolie: depends on what you need
[09:56] <poolie> the problem is that many are just toys
[09:56] <poolie> and, right, people have different ideas of what is useful
[09:56] <pitti> poolie: the one you pointed me to is great for actually doing work in Launchpad
[09:57] <pitti> poolie: I use lp-shell for testing code snippets using launchpadlib before I put them into programs
[09:57] <poolie> where do you put them?
[09:57] <pitti> not for actually doing stuff on LP
[09:57] <pitti> poolie: apport, for example
[09:57] <pitti> or the work item tracker
[09:57] <poolie> yay apport :-)
[09:58] <qwer> Wholy fucking shit - a bios update fixed EVERYTHING! And I've been using this hardware for 4 years...
[10:04] <persia> !ohmy
[10:08] <cjwatson> I find lp-shell useful for when I'm doing odd one-off things nobody has thought to write explicit programs for yet
[11:05] <dholbach> ifupdown 0.6.8ubuntu21.1 in karmic-proposed tries to overwrite etc/init.d/networking from netbase
[11:05]  * Mamarok was going to report the same :)
[11:06] <pitti> Mamarok, dholbach: erk, can you please report this to bug 497299?
[11:06] <pitti> weird though, the package just changed the postinst
[11:07] <Mamarok> done
[11:11] <dholbach> pitti: http://paste.ubuntu.com/381526/
[11:12]  * pitti removes that version from -proposed
[11:13] <pitti> thanks for the report
[11:13] <dholbach> no worries
[11:14] <pitti> bug updated accordingly
[11:14] <pitti> slangasek: ^ FYI
[11:38]  * ogra tries out seb128's fixed upload ...
[11:39] <ogra> seb128, still the flickering dots in xchat
[11:39] <seb128> ogra: talk to bratsche when he will be there
[11:39] <ogra> yep
[11:40] <seb128> I still get the slowness issue too
[11:40] <ogra> same here
[11:40]  * ogra downgrades gtk again
[11:40] <seb128> so I guess his fixes is not working as expected
[11:40] <ogra> sadly that makes evo unhappy
[11:42] <ogra> ah, better ... gdm looks intresting though with the clinet side frames :)
[11:49] <cjwatson> ArneGoetje: pinyin-database looks like it may need an MIR for promotion to main?
[12:07] <tseliot> mdeslaur: do we ship 64bit flash on amd64?
[12:07] <tseliot> (in lucid)
[12:10] <tjaalton> tseliot: no
[12:10] <tseliot> tjaalton: oh, do you know why?
[12:10] <tjaalton> aiui adobe doesn't want people to ship prerelease versions
[12:11] <tjaalton> there should be a bug about it
[12:11] <tjaalton> s/should be/is/
[12:13] <tjaalton> tseliot: bug 331275
[12:13] <tseliot> tjaalton: thanks
[12:13] <cjwatson> dpm: did you see my request for branch recreation in bug 518718?
[12:14] <dpm> cjwatson, yeah, thanks, I just haven't had the chance to do it
[12:17] <cjwatson> james_w: I'm getting hourly e-mails about "spiv/jam" not being a valid Launchpad account in foundations-lucid-distributed-development work items; can that be regularised?
[12:18] <dpm> pitti, could you please copy the latest karmic PPA to karmic-proposed when you've got some time? They include a fix in FF translations generated with po2xpi which would be good to get tested
[12:19] <dpm> (the language packs, I mean)
[12:26] <pitti> dpm: sure, running
[12:27] <dpm> cool, thanks pitti!
[12:59] <davmor2> pitti: https://bugs.launchpad.net/bugs/422536 seems to of crept back into Lucid.
[13:02] <dholbach> **
[13:10] <pitti> davmor2: eww; mind to reopen it then with a comment?
[13:11] <davmor2> pitti: no probs
[13:15] <nigelb> pitti: hey, you got some time?
[13:15] <nigelb> wondering how to make a report from an apport hook automatically private
[13:15] <pitti> nigelb: I need to leave in 10 mins for some 2.5 hours, so only if it's quick
[13:15] <nigelb> I've been working on a hook for rhythmbox, so some of the data might be private
[13:16] <pitti> but if it's a private bug, nobody will be able to see it..
[13:16] <pitti> nigelb: wouldn't it be better to filter out the potentially private bits?
[13:16] <nigelb> I'm working on that right now
[13:16] <nigelb> but, otherwise, there is no way to make the report private?
[13:17] <pitti> nigelb: we could add that to apport relatively easily
[13:17] <pitti> like report['Private'] = 'Yes'
[13:17] <pitti> report['Subscribers'] = 'ubuntu-core-dev'
[13:18] <nigelb> oh, that works now?
[13:18] <pitti> but I don't think it's a very clean use case
[13:18] <pitti> nigelb: no, it doesn't right now
[13:18] <nigelb> from the angle of how many people can work on the bug, I agree, it looks messy
[13:18] <pitti> we sort of have to deal with it for crashes, but for hooks we might just better try to obfuscate/filter sensitive stuff
[13:18] <nigelb> it would mean only bug control and a small group of people can see the report
[13:19] <nigelb> I'll get around to filtering it then.  Thanks :)
[13:19] <pitti> nigelb: like, if you dump the DB, you could replace all file and tag names with a dummy
[13:19] <pitti> so that structural damage is detected, but no actual information exposed
[13:19] <pitti> credentials from the music stores should of course be filtered out entirely
[13:20] <pitti> nigelb: ok, good luck! if you have further questions, I'll answer scrollback once I'm back
[13:20] <nigelb> I'm just getting a dump of gconf data.  I've figured of all fields that needs to be removed, so the data in the fields is going to be replaced with ##masked##
[13:20] <pitti> nigelb: for the ease of triaging, you might just check their validity, and remove them altogether?
[13:21] <pitti> i. e. see what you would like to look at as a triager, and try to automate that, so that the "unusal" bits stand out
[13:21] <pitti> anyway, need to go, cu later
[13:21] <nigelb> okay :)
[13:21] <persia> So we just get a nice report "Database OK" or "Database corrupt", or similar?
[13:22]  * nigelb frowns
[13:22] <nigelb> thats a lot of work
[13:22] <nigelb> persia: this is what I have right now.  Its not much.  the masking is not working (yet), http://etherpad.com/nJwmxU3dGv
[13:24] <persia> nigelb: I think you want to capture some data about the pulse configuration as well.  Maybe crimsun has a good suggestion for that.
[13:24] <nigelb> I thought "report.add_package_info("pulseaudio")" did that
[13:24] <persia> (or at least with my limited python it appears you're capturing gstreamer and alsa config, but not pulse config)
[13:25] <nigelb> the pulse bit it between alsa and gstreamer
[13:25] <persia> Oh, I missed that bit, perhaps because it came after the paplay call.
[13:25]  * persia apologises for the unnecessary highlight
[13:25] <nigelb> the more eyeballs it get, the more bugs i correct
[13:26] <nigelb> (otherwise, I would have never known the earlier wav didn't work)
[13:39] <ogra> seb128, ha ! my armel desktops are not affected by the csd bug :)
[13:39] <ogra> we should just all switch to armel :)
[13:39] <seb128> lol
[14:16] <soren> cjwatson: I just stumbled upon bug 246558. I'd still love to get that fixed. Do you have an opinion on the approach taken in my patch? The patch is a couple of years old, so probably needs fixing up.
[14:20] <nigelb> seb128: do you deal with merges for rhythmbox?
[14:20] <seb128> nigelb, yes, why?
[14:20] <nigelb> seb128: I'm merging an apport hook :)
[14:20] <nigelb> or requesting a merge for rather
[14:20] <seb128> hum, what we call merge usually is taking debian changes
[14:20] <seb128> that's rather sponsoring
[14:20] <nigelb> sorry, should have been more clearer
[14:21] <seb128> nice, thanks, I will have a look to that
[14:21] <nigelb> just doing it locally now, will ping you once finished
[14:21] <seb128> ok thanks
[14:23] <zul> soren: ssh uses upstart now as well fyi
[14:25] <soren> zul: Really? The package still ships an init script?
[14:25] <soren> Bah, I'm on crack.
[14:25]  * soren can't spell "init"
[14:26] <zul> heh
[14:29] <cjwatson> soren: doing anything like this at boot makes me uncomfortable - I keep imagining Scott turning up at my door with an axe
[14:30] <cjwatson> soren: and this patch wouldn't deal with Bjorn's use case, because of the special postinst handling of no HostKey directives
[14:31] <cjwatson> all looks rather tricky :(
[14:32] <soren> I never understood the no-hostkey thing.
[14:32] <soren> How does openssh do without a hostkey?
[14:33] <cjwatson> I thought Bjorn explained that
[14:33]  * soren rereads
[14:33] <cjwatson> #ifndef GSSAPI
[14:33] <cjwatson>         /* The GSSAPI key exchange can run without a host key */
[14:33] <cjwatson>         if ((options.protocol & SSH_PROTO_2) && !sensitive_data.have_ssh2_key) {
[14:33] <cjwatson>                 logit("Disabling protocol version 2. Could not load host key");
[14:33] <cjwatson>                 options.protocol &= ~SSH_PROTO_2;
[14:33] <cjwatson>         }
[14:33] <cjwatson> #endif
[14:33] <cjwatson> (sshd.c)
[14:33] <soren> I see.
[14:34]  * soren goes to a phone call
[14:55] <james_w> davmor2: hey, could you open a new bug for the EDAC warning thing please?
[14:56] <davmor2> james_w: I can indeed
[14:56] <mdeslaur> Is it possible to use an icon from a path when porting a python app to application indicators?
[14:56] <james_w> that bug is too huge and horrible to be useful
[14:56] <james_w> I want it to go away
[14:56] <davmor2> james_w: np's 2 ticks
[14:56] <james_w> thanks davmor2
[15:03] <davmor2> james_w: bug 525792
[15:03] <james_w> davmor2: you are getting this as an apport popup?
[15:04] <davmor2> james_w: Yeap
[15:04] <james_w> thanks
[15:07] <sgnb> anyone here willing to help with OCaml transition (#522358, #522363)?
[15:09] <davmor2> james_w: Is there anything else you'd like adding that might be useful?
[15:09] <james_w> davmor2: a patch? :-)
[15:10] <james_w> davmor2: I understand the issue and your logs that apport attached should be sufficient to work out why the pattern isn't matching to ignore this issues
[15:10] <davmor2> james_w: Hmmmm a patch from me do you hate the kernel?
[15:11] <james_w> davmor2: it's not really a kernel issue
[15:11] <james_w> though I don't think it should be acting like this
[15:11] <james_w> the issue is with kerneloops, it shouldn't be causing an apport report for this issue, I just reassigned
[15:12] <BenC> Good morning software scally wags
[15:13] <mdeslaur> tedg: Is it possible to use an icon from a path when porting a python app to application indicators?
[15:15] <tedg> mdeslaur: Not currently.  Do you have a use-case?  Why is the icon not installed?
[15:20] <mdeslaur> tedg: well, I started to port virt-manager to app indicators, and it's icons are in it's own directory...
[15:21] <tedg> mdeslaur: Is it in an "icon-theme" format?  Like with all the different sizes?
[15:22] <tedg> mdeslaur: If so, you just need "new_with_path" which installs an icon theme path, but I think that's not in the Python bindings for some reason.
[15:22] <mdeslaur> tedg: unfortunately not, it's just a single icon in a directory
[15:23] <tedg> mdeslaur: :-/  We probably should fix that... can we just install it in /usr/share/icons/hicolor ?
[15:23] <tedg> mdeslaur: (that's the spec locations for one-of icons)
[15:24] <qense> tedg: we did find an appindicator.icon_path property, but that was the only reference to an icon path we could find.
[15:24] <qense> I've also got a problem with an icon being located in /usr/share/pixmaps/{appname}/{appname}_tray.png
[15:24] <qense> at*
[15:26] <jcastro> mdeslaur: did you file a bug for virt-manager app indicators?
[15:26] <tedg> qense: Yeah, it needs to be built at construction time.  So in the current Python bindings you really need the special _new function.  With PyGI it would be possible to se it.
[15:26] <mdeslaur> tedg: ok, I'll try putting a symlink in there
[15:26] <mdeslaur> jcastro: LP #525462
[15:26] <jcastro> ta
[15:43] <nxvl> kirkland: ping
[15:43] <kirkland> nxvl: yo
[15:43] <nxvl> kirkland: are you still maintaining encrypted home directory?
[15:44] <nxvl> kirkland: a friend of mine hited a really weird bug
[15:44] <nxvl> and i was able to reproduce it
[15:45] <kirkland> nxvl: yes
[15:45] <kirkland> nxvl: what's the bug?
[15:45] <nxvl> kirkland: if you have EHD, and change the user password from A to B, then reboot, for some reason the system won't accept B, but it will A, but your HD won't get decrypted
[15:47] <nxvl> kirkland: (change the password using the UI, haven't tried using passwd)
[15:50] <kirkland> nxvl: you can successfully change the password as the user, using either passwd or System->Preferences->About Me->Change password
[15:51] <kirkland> nxvl: but you can't use the admin user to force-overwrite the user's password, using passwd or System->Administration->Users
[15:51] <nxvl> i used.... System > Administration > Users and Groups
[15:51] <kirkland> nxvl: because if the admin does it, the admin is not prompted for the user's old password
[15:51] <kirkland> nxvl: note that this is fixed in Lucid
[15:51] <kirkland> nxvl: the key is that we need to "re-wrap" the passphrase
[15:51] <kirkland> nxvl: for that, we need the old password and the new password
[15:52] <nxvl> kirkland: actually i used the same user to change it's own password, and it was indeed prompted for the old password
[15:52] <kirkland> nxvl: are you *sure*?
[15:52] <kirkland> nxvl: i bet you were prompted by gk-sudo to run that app
[15:52] <kirkland> nxvl: and then you were asked for the user's new password, and that's all
[15:52] <kirkland> nxvl: is this 9.10?
[15:53] <nxvl> kirkland: i went to Users and Groups, the selected the user, clicked properties, click on change password, it asked me for the current password, once i hitted autenticate it unblocked the new password and repeat pasword input field
[15:53] <nxvl> kirkland: yup, 9.10
[15:53] <kirkland> nxvl: yes, the first password you entered just unlocked administrator mode
[15:53] <chrisccoulson> nxvl - if you're referring to users-admin, did you use it to change somebody elses password?
[15:53] <kirkland> nxvl: it was not used in the passwd call
[15:54] <kirkland> nxvl: hence the problem
[15:54] <kirkland> nxvl: again, i note, look at the behavior in Lucid -- this is fixed
[15:54] <nxvl> chrisccoulson: nope
[15:54] <nxvl> kirkland: no, not the onlocking
[15:55] <chrisccoulson> nxvl - that should work in karmic too if you are changing your own password
[15:55] <nxvl> kirkland: on the users and groups dialog you have a button with keys on it, that's the one to unlock, that's NOT the one i pressed
[15:55] <chrisccoulson> is gnome-about-me installed?
[15:55] <nxvl> kirkland: i selected the user (i.e. nxvl) from the list the dialog shows
[15:55] <nxvl> kirkland: then clicked properties on the right
[15:56] <nxvl> kirkland: once in that new dialog there is another button "Change Password..."
[15:56] <nxvl> clicked on that and a "Change password" dialog apeared
[15:56] <nxvl> let me take a screenshort
[16:01] <nxvl> kirkland: how do i upload to people.ubuntu.com?
[16:01] <kirkland> nxvl: it's people.canonical.com now
[16:01] <nxvl> oh, ok
[16:02] <jpds> nxvl: That or: https://wiki.ubuntu.com/PeopleUbuntuCom
[16:03] <nxvl> kirkland: http://people.canonical.com/~nxvl/change_password.png\
[16:03] <nxvl> kirkland: http://people.canonical.com/~nxvl/change_password.png
[16:03] <chrisccoulson> that dialog is part of gnome-control-center
[16:03] <chrisccoulson> i'd be surprised if that doesn't work. it just calls passwd
[16:04] <nxvl> it doesn't, it seems that it changes something in cryptfs, but not the password itself in the system
[16:04] <nxvl> is really weird
[16:05] <kirkland> nxvl: fwiw, i have this script in my ~bin/pcc, pcc=people.canonical.com: http://people.canonical.com/~kirkland/pcc
[16:05] <kirkland> nxvl: so i can just pcc <FILE> or pcc <DIR>
[16:05] <kirkland> nxvl: yep, this is broken in 9.10
[16:06] <kirkland> nxvl: because the "authenticate" step is separate from the change password step
[16:06] <nxvl> oh really?
[16:06] <kirkland> nxvl: so the password given in the first step is NOT passed to passwd on the change password
[16:06] <kirkland> nxvl: rather, after being authenticated, it just force changes the password as root
[16:06] <kirkland> nxvl: so i'm telling you ...
[16:06] <nxvl> ohhh
[16:06] <kirkland> nxvl: a) this is fixed in Lucid
[16:06] <nxvl> ok, that makes sense
[16:07] <kirkland> nxvl: b) use passwd on the command line
[16:07] <kirkland> nxvl: or c) use About Me to change password
[16:07] <chrisccoulson> kirkland - the gnome-about-me dialog should actually work though (it passes the old password to passwd)
[16:07] <kirkland> nxvl: and if you really want this fixed, then propose an SRU or something
[16:07] <kirkland> chrisccoulson: absolutely, About Me will definitely work
[16:07] <chrisccoulson> the one with the issue was users-admin, which we worked around in karmic by calling gnome-about-me
[16:07] <chrisccoulson> but the dialog nxvl shows is the gnome-about-me dialog
[16:07] <kirkland> chrisccoulson: hrm
[16:08] <nxvl> kirkland: oh yeah, actually it is
[16:08] <nxvl> i just tried the About me and got the same dialog
[16:20] <randomaction> Can some core dev(s) please help with the OCaml transition? Currently 2 packages are waiting for a sync ACK (bug 522358), and 2 packages need to be rebuilt (bug 522363).
[16:20] <randomaction> In total, around 100 uninstallable packages are blocked on this.
[16:23] <pitti> randomaction: the two syncs are already approved
[16:23] <pitti> randomaction: do you need them synced right now?
[16:30] <pitti> randomaction: hevea/ocaml synced
[16:30] <pitti> "jocaml"
[16:37] <pitti> randomaction: and the two rebuilds uploaded
[16:37] <randomaction> pitti: thanks for that
[16:38] <pitti> randomaction: oh, seems I missed camlp5; syncing
[16:42] <randomaction> pitti: great, thanks again!
[16:42] <randomaction> james_w: thank you, too
[16:43] <randomaction> sgnb: round 2 complete (except for actual building)
[16:43] <Laney> bah
[16:43] <Laney> you guys and your easy ocaml transition!
[16:44] <Laney> ghc6 is having trouble even building...
[16:46] <randomaction> sgnb: for the next rounds, it'll probably be more handy filing separate bug reports for packages in main and universe
[16:47] <nigelb> seb128: bzr merge requested for rhythmbox apport hook :)
[16:47] <seb128> nigelb, thanks
[16:47] <nigelb> :)
[16:48] <sgnb> randomaction: I've just added two packages for round 2 that I overlooked
[16:48] <sgnb> randomaction: you mean 4 bugs per round?
[16:49] <sgnb> (i.e. {main,universe} x {sync,rebuild})
[16:49] <Laney> can't you just poke a friendly archive admin with a list of stuff to sync?
[16:49] <sgnb> Laney: I don't know any
[16:50] <randomaction> Laney: that's a more efficient way to handle a transition :)
[16:50] <sgnb> (I mean, I don't know any archive admin... not that all archive admin are not friendly)
[16:52]  * Laney is sure that some read this channel :)
[16:53] <sgnb> Laney: what's the difference between archive admins and sponsors?
[16:53] <sgnb> (in Debian, archive admins mostly don't care about transitions)
[16:54] <nigelb> seb128: hold off, I made a mistake.  will correct and push again
[16:54] <seb128> nigelb, ok
[16:54] <Laney> sgnb: Archive admins push the buttons to make syncs happen
[16:55] <Laney> and other things like handling removals
[16:55] <sgnb> ok
[16:55] <Laney> and NEWing, kind of like ftpmasters
[16:55] <sgnb> Laney: but how are rebuilds handled?
[16:55] <Laney> by doing a new sourceful upload
[16:55] <sgnb> (most of the work is in rebuilds)
[16:56] <Laney> don't need archive admin powers to do that, just upload access
[16:56] <sebner> Laney: NEW is so awfully full *hrhrhrhr*
[16:58] <sgnb> Laney: there are no such things as binNMUs, right?
[16:58] <Laney> nope (sadly)
[16:59] <nigelb> seb128: Done.  Sorry. I forgot to change changelog from karmic to lucid :)
[17:03] <randomaction> sgnb: I'm confused about confluence and ocamldsort, they only depend on libc6, do they need to be updated?
[17:04] <sgnb> randomaction: they depend on ocaml on armel and ia64 (aka "bytecode" architectures)
[17:04] <nxvl> james_w: hi
[17:05] <nxvl> james_w: i just hitted BTS #570504
[17:05] <sgnb> (and btw, I've juste understood why I overlooked them at first)
[17:05] <nxvl> james_w: is there a workaround or something i can do to use bzr bd?
[17:05] <nxvl> i kinda need it
[17:05] <seb128> nigelb, do you have a bug about this change?
[17:06] <james_w> bug 570504
[17:06] <james_w> debian bug 570504
[17:06] <nxvl> mm ubottu sould know what BTS is
[17:07] <randomaction> sgnb: ok, I missed that on i386 :)
[17:07] <james_w> nxvl: hmm, I'm not sure of how to workaround this without editing files
[17:07] <james_w> nxvl: I can tell you what change to make to fix it if you want to edit the files on your system
[17:07] <james_w> or you could use lp:bzr-builddeb temorarily
[17:08] <nxvl> james_w: would those changes be overriden by the next package installed?
[17:08] <james_w> yeah
[17:08] <nxvl> james_w: as in, when the package with the fix is uploaded to the ppa, would the files edited dump the changes?
[17:08] <james_w> yeah
[17:08] <nxvl> then i can edit some files, will take a look at the patch in the branch
[17:10] <nigelb> seb128: no
[17:11] <seb128> nigelb, can you maybe open one and put the url for the change there?
[17:11] <cjwatson> jcastro: I was about to go and fix bug 494282, but I see you're assigned to it - do you need a branch merged or anything?
[17:11] <seb128> it's easier to keep track of those
[17:11] <seb128> I'm not even sure I get bug emails otherwise
[17:12] <cjwatson> dup> er, yeah, that one
[17:12] <nigelb> seb128: you mean open a bug and put a closes into changelog?
[17:12] <seb128> nigelb, just open a bug, I'm going to do a new git snapshot
[17:12] <seb128> so I will tweak changelog anyway
[17:12] <nigelb> will do :)
[17:12] <seb128> but I got nothing now, I think I don't get those merge request emails
[17:13] <nxvl> james_w: what's the revision with the fix? i don't find the patch
[17:13] <seb128> we usually use sponsoring bugs rather for desktop changes
[17:13] <seb128> nigelb, thanks
[17:13] <nxvl> james_w: nm, found it
[17:13] <nigelb> seb128: ah, I know, but this is not exactly a bug, thats why went this route
[17:13] <seb128> well a feature request
[17:14] <seb128> or a sponsoring request
[17:14] <seb128> all the same we use bug reports
[17:14] <nigelb> will do this in the future :)
[17:14] <jcastro> cjwatson: I was going to fix it when we upload the free culture showcase winner.
[17:14] <seb128> nigelb, thanks
[17:14] <jcastro> cjwatson: feel free to do it now if you want!
[17:15] <nxvl> james_w: works \o/
[17:15] <james_w> score
[17:15] <james_w> thanks for testing
[17:15] <nigelb> seb128: bug 525888 opened :)
[17:15] <seb128> nigelb, thanks
[17:22] <jdong> hmm, after archive reorg, seems like I lost my magic powers to upload to the -backports pocket...
[17:22] <jdong> *sniff sniff*
[17:23] <jdong> can an archive admin / core-dev take a look at bug 411849 please? sponsor the debdiff in the initial comment to hardy-backports?
[17:23] <cjwatson> ... I didn't know you had such powers?  didn't the TB say it should be core-dev only for direct uploads?
[17:24] <jdong> cjwatson: that was what it was supposed to be, yeah, but for quite some time I seemingly posessed the power to do so
[17:24] <jdong> maybe that was by error/accident :)
[17:25] <jdong> I seem to recall we had a conversation about it (or maybe it was just ScottK) and concluded that the ACL was okay since an archive-admin has to prod it through anyway
[17:25] <cjwatson> not aware of archivereorg affecting this
[17:26] <Laney> any developer could upload to -backports
[17:26]  * Laney has done so before
[17:26] <jdong> Laney: I just got shot down :)
[17:26] <jdong> Signer is not permitted to upload to the component 'main'.
[17:26] <jdong> maybe it's -universe only for MOTU?
[17:26] <jdong> "MOTU"
[17:26] <Laney> you can probably find a backport to test with
[17:27] <jdong> Laney: or find someone who knows the answer ;-)
[17:27] <Laney> bah, that's no fun!
[17:28] <shtylman_> has the libmysqlclient situation been unmangled?
[17:36] <pitti> shtylman_: yes
[17:37] <shtylman_> pitti: when will that hit the repos? any idea?
[17:37] <pitti> shtylman_: last week :)
[17:38] <shtylman_> pitti: really?
[17:38] <shtylman_> pitti: http://packages.ubuntu.com/lucid/liblua5.1-sql-mysql-2
[17:38] <shtylman_> I look at that ... and that one in particular is still on 15
[17:38] <pitti> libmysqlclient16 | 5.1.41-3ubuntu6 |         lucid | amd64, i386
[17:38] <pitti> shtylman_: if you have the 7 version installed locally, you need to purge it
[17:39] <shtylman_> pitti: k... I will try that
[17:39] <persia> shtylman_: You may find rmadison more usefully informative than packages.ubuntu.com
[17:41] <shtylman_> persia: thanks
[17:41] <cjwatson> jcastro: ok, thanks, will do
[17:41] <cjwatson> happened to see YA duplicate of it going past ...
[17:43] <james_w> was the entirety of mysql-cluster nuked?
[17:43] <james_w> it's in binary NEW, and all the binaries it builds are showing as new
[17:50] <shtylman_> pitti: is there a nice way to purge that package without also uninstalling what depends on it?
[17:50] <pitti> shtylman_: does somethign depend on it?
[17:51] <pitti> shtylman_: I could just purge it here; it had one other library dependency which got purged along
[17:51] <pitti> shtylman_: if you actually need it, use apt-get install libmysqlclient/lucid
[17:51] <shtylman_> libmysqlclient16 yea... when I purge it .. it also wants to remove akonadi ... etc
[17:51] <james_w> would apt-get install libmysqlclient16=5.1.41-3ubuntu6 work
[17:51] <cjwatson> dpkg --purge --force-depends
[17:51] <james_w> possibly with --force-downgrade
[17:51] <cjwatson> (BE VERY CAREFUL)
[17:51] <pitti> james_w: libmysqlclient/lucid should do that as well, it downgrades
[17:51] <cjwatson> installing a lower version explicitly is definitely better if you can
[17:51] <pitti> sorry
[17:52] <pitti> apt-get install libmysqlclient16/lucid
[17:52] <pitti> (forgot the number)
[17:52] <shtylman_> the lower version install worked
[17:52] <shtylman_> thanks all :)
[18:01] <nailora> there is bug 11334 that i am following for quite some time because it bugs me, too :) it is about what happens to the clipboard contents when an application quits. discussion has become more and more off-topic, and there seems to be a lack of developer participation. i'd like to know how to proceed with this...
[18:04] <nailora> it is somewhat broken deep within the x-server (or the spec the x-server follows). or nearly all application just do not to the right thing as it can be fixed on application level, too. but this will not happen for all legacy applications. clipboard managers are not the solution but a workaround, but waiting for a solution in x.org/the spec x.org follows will take lots of time and a workaround might be good in the meantime... ...
[18:04] <genii> I have Intel Pro/1000 XF (fibre optic card) ethtool is reporting only 1000 Base T (copper) capability (when should be 1000 Base FX). Is there some known prob/fix for the e1000 driver?
[18:05] <cjwatson> nailora: workaround: use a clipboard manager application, that takes a copy of the clipboard contents and stashes it
[18:06]  * pitti reenables hourly WI tracker updates, sorry
[18:06] <cjwatson> it's an X design issue, I wouldn't expect it to be fixed any other way
[18:06] <cjwatson> indeed I don't think it is *fixable* any other way
[18:07] <nailora> cjwatson: i know that and i do it it that way personally. but arguably this should "just work" for everyone. that would require a solution that could be included in the default installation
[18:07] <cjwatson> if you're starting from the position that "clipboard managers are not the solution but a workaround", then there is no other option except to wait for (or participate in?) an X design fix
[18:08] <cjwatson> X clipboard clients ask the clipboard owner (an application) for clipboard contents when they need it, and if the application exits then there's no owner to respond; there's no way that can be an application bug
[18:09] <chrisccoulson> which applications don't work correctly?
[18:09] <chrisccoulson> i could only recreate that with firefox, and that's been fixed upstream recently
[18:10] <cjwatson> maybe something is managing the clipboard centrally now?
[18:10] <nailora> it seems that upon exiting an application is able to ask the x server to preserve the contents somehow (most gnome apps and notably firefox nowadays do it). so it can be fixed on application level
[18:12] <jdong> isn't that something introduced way bac: http://library.gnome.org/misc/release-notes/2.12/#rngeneral
[18:12]  * cjwatson is just five seconds late with the same link
[18:12] <chrisccoulson> the clipboard is still based around the selection mechanism
[18:12] <nailora> but most apps simply do not do that. and somehow it seems redundant that you have to request this "feature" if i cannot think of a situation where you would not want it. so it should be default to save the contents and thus be handled in x.org (even so contents from crashing applications would still be lost that way).
[18:13] <cjwatson> gnome-settings-daemon, apparently
[18:13] <chrisccoulson> but applications that don't work explicitly destroy these resources when they close
[18:13] <nailora> therefore i think a push solution (instead of pull like now) is in fact better (and clipboard managers are basically transforming it from pull to push)
[18:14] <cjwatson> nailora: do you have evidence that applications need to explicitly request this feature?
[18:16] <cjwatson> the current state appears to be basically just a clipboard manager built into gnome-settings-daemon
[18:17] <cjwatson> I don't see any application-level requests going on - gnome-settings-daemon responds to various X events
[18:17] <nailora> however todays clipboard managers are to much bling bling. they should run in the background, have no gui, just make things work. history and stuff like current implementations offer could optionally be added for power users). and something sensible should be done with binary data in case applications offer different content depending on the receiver (notably the gimp does this). these things could be fixed easily. but no developer commen
[18:17] <cjwatson> nailora: gnome-settings-daemon's clipboard manager runs in the background, with no bling
[18:17] <cjwatson> no UI at all AFAICS
[18:18] <nailora> no i have no strong evidence, it is just how i understood the discussion in the bug
[18:18] <cjwatson> you're making some assertions that don't seem to match how the code works
[18:18] <cjwatson> at this point, I imagine that developers are put off commenting on the bug simply because it's one of those enormous unmanageable bugs
[18:18] <nailora> cjwatson: gnome-settings-daemon's clipboard manager does not seem to fix all problems
[18:19] <cjwatson> this is why bugs need to be kept small and focused, and why jumping into an existing bug to expand its scope tends to be harmful
[18:19] <nailora> so you basically are suggesting a new bug should be opened containing a short&precise list of applications that are still broken and an overview about the possible solutions?
[18:19] <cjwatson> ah, let's see, there's a SAVE_TARGETS request
[18:19] <cjwatson> not suggesting that at all
[18:20] <cjwatson> I'm suggesting that, if it works for many applications, there ought to be a separate individual bug against each application that seems to have a problem in conjunction with the clipboard
[18:20] <cjwatson> grab-bag bugs are fundamentally doomed
[18:21] <cjwatson> apologies for not noticing SAVE_TARGETS before now, that supports the application-request assertion you made
[18:21] <nailora> installing a clipboard manager by default would have solved all the issues so it was not unreasonable to group it at that time.
[18:22] <cjwatson> it may not have been unreasonable, but it was never going to work well :)
[18:22] <nailora> when favoring the fix-every-application-solution this massive collection is counterproductive
[18:23] <cjwatson> http://www.freedesktop.org/wiki/ClipboardManager seems to be the closest thing that's going to happen to a spec-level change
[18:23] <nailora> but it seems as if this is not a simple "bug" but something that needs more discussion
[18:23] <nailora> has been featured in forums & brainstorm too
[18:23] <cjwatson> it seems reasonable to file separate bugs against individual applications (presumably non-GTK applications, for the most part? don't know about Qt) that don't support it
[18:30] <nailora> just tried dolphin and it fails :)
[18:32] <nailora> so yeah, perhaps all qt-apps could be fixed with one change. this would be a big improvement but still leaves a lot more apps. but it shows why the "applications can request this feature" is the wrong default imho. apps should be allowed to opt-out but have it enabled by default because that way data loss is prevented.
[18:35] <slangasek> pitti: sorry about that; ifupdown reuploaded
[18:39] <pitti> slangasek: ah, thanks; what happened there?
[18:40] <slangasek> pitti: ifupdown hadn't been rebuilt with the karmic-final version of debhelper, so this conflict went unnoticed; was already fixed in lucid, but I'd forgotten about it and didn't do a test install of ifupdown on karmic before upload, thinking it was a trivial change :/
[18:41] <pitti> I suspected something like that when the problem was reported, but it wasn't obvious that something like that could happen when I reviewed the diff
[18:41] <pitti> thanks for the fast fix
[18:41] <pitti> I'll check/accept it right away
[18:45] <slangasek> pitti: ta!
[18:54] <mrenouf> Is it possible to make unattended-upgrade work like 'apt-get distupgrade' ? Specifically, permit it to install versions with new dependencies?
[18:54] <mrenouf> I'm now reading the apt source for clues ;-)
[18:57] <slangasek> cjwatson: hmm, we have a topic lock here?
[18:57] <cjwatson> slangasek: maybe imposed during the last days of hyperion?
[18:57] <cjwatson> (sounds like a Dan Simmons novel)
[18:58] <slangasek> heh
[18:58] <slangasek> cjwatson: could you unset, or add a mention of FF? :)
[18:59] <cjwatson> unset
[18:59] <slangasek> cheers
[19:14] <mathiaz> bdmurray: hi! I'd like to add a query to bughugger
[19:15] <mathiaz> bdmurray: I'd like to generate a list of bugs to which the ubuntu-server is subscribed, that are in New,Undecided and that haven't been created today
[19:16] <mathiaz> bdmurray: being able to filter by date in LP is not possible from the advanced search AFAICT
[19:16] <mathiaz> bdmurray: the next option I'm looking into is bughugger
[19:20] <ccheney> anyone notice thinkpads not spinning their fans up enough to cool down?
[19:20] <tkamppeter> pitti, hi
[19:20] <Pici> ccheney: Yes.  But I thought it was just mine, I had to replace the fan not that long ago and thought it might be acting up again.
[19:20] <ccheney> i'm building webkit and the cpu is up to 87C
[19:21] <mrenouf> ouch
[19:21] <ccheney> and the fan doesn't seem to be making too much noise
[19:21] <kklimonda> ccheney: 87C is bad? My get up to 99C :/
[19:21] <ccheney> kklimonda: its still climbing
[19:21] <Pici> I hit 102C the other day.
[19:21] <ccheney> iirc my system has gotten in the mid 90s before and starting having errors
[19:22] <kklimonda> my started acting strange when it got over 100C once :/
[19:22] <kklimonda> gcc was segfaulting
[19:22] <ccheney> i'm not sure what the max speed of the fan is supposed to be but it claims to be at ~ 4300rpm
[19:22] <mrenouf> if you're doing something cpu intensive for long periods of time, i'd recommend a stand where there is free airflow around all sides
[19:23] <ccheney> its sitting on a flat desk with plenty of airflow
[19:23] <Pici> Anyone know if there is already a bug logged for this?
[19:23] <kklimonda> my laptop is going to die anyway - I'm a lucky owner of the nvidia gpu from G86 serie..
[19:24] <kklimonda> Pici: is it even a bug? laptops get hot. period. :)
[19:25] <mrenouf> well if you could simulate the same cpu activity under windows and that results in lower sustained temps. then yes. it's a bug.
[19:25] <ccheney> 89C now
[19:26] <ccheney> handrest is very warm :-\
[19:26] <ccheney> i guess i'll try testing out the windows side after this build completes or dies due to heat, heh
[19:26] <kklimonda> mrenouf: well - I've noticed that laptops get hotter when running linux in the idle but last time I've checked I could get my laptop to about 99C using Windows so I'm not sure if there is a bug
[19:26] <ccheney> also i could try 9.10 or 9.04 to make sure it doesn't have the same issue also
[19:27] <kklimonda> ccheney: have you tried cleaning it up?
[19:27] <ccheney> hmm?
[19:27] <ccheney> compressed air i suppose? just did that
[19:27] <kklimonda> ccheney: using compressed air or a vacuum cleaner to get all the dust out of it ;)
[19:27] <ccheney> it seems to have cooled it down at least temporarily
[19:27] <bdmurray> mathiaz: http://qa.ubuntu.com/reports/team-subscribed/ubuntu-server-subscribed-bug-tasks.json would likely be a good a start
[19:28] <ccheney> it was suprisingly dusty
[19:28] <bdmurray> mathiaz: I could add in date_reported as a field then you could filter that result set with bughugger
[19:28] <kklimonda> ccheney: well - you just have to believe in linux and your laptop to shut down itself when temperature gets critical
[19:28] <mathiaz> bdmurray: that would be great!
[19:28] <ccheney> yea
[19:28] <mathiaz> bdmurray: how do I add a filter by date in bughugger?
[19:29] <kklimonda> ccheney: I have an old T23 with a broken fan and it can get up to 103-104C and then system shuts down
[19:29] <ccheney> actually its staying lower temp, i might have to run the build again to make sure that solved it, but its looking good so far :)
[19:29] <ccheney> already down to 69C
[19:29] <bdmurray> mathiaz: well the data (date reported) would need to be there first ;-)  I'll set it up and e-mail you or something
[19:29] <tlyu> ccheney: it ingested a dustbunny that didn't agree with it?
[19:30] <mathiaz> bdmurray: great - thanks!
[19:30] <kklimonda> after I've cleaned up my T61 recently it idles at around 53C for cpu and 55C for gpu
[19:30] <ccheney> tlyu: seems to have, lol :)
[19:30] <mathiaz> bdmurray: does ubuntu-server-subscribed-bug-tasks.json include the list of bugs for packages to which the ubuntu-server team is a bug contact?
[19:30] <ccheney> but it might not be doing as much work atm, so will need to rerun the build or run cpuburn to verify
[19:31] <ccheney> it definitely had a disturbing amount of dust that blew out
[19:31] <bdmurray> mathiaz: yes
[19:31] <kklimonda> yeah, it's hard to believe how much dust can you blow out of your laptop :)
[19:31] <ccheney> it seems to just be linking now instead of compiling so that may be part of the reason it cooled down
[19:32]  * ccheney needs another can of air
[19:36] <csurbhi> i have a question on acpi bios... i want to blacklist an acpi bios.. the options for blacklisting are a "system id" or "board id" .. i am in favor of using a board id as i think that a bios will be dependent on the board rather than the machine/laptop
[19:36] <csurbhi> for eg: dell inspiron laptop (which shows an acpi bug) could have a different motherboard and then the bug may not show its face..
[19:36] <csurbhi> oops.. wrong window :P
[19:40] <ccheney> so far on the new build hasn't gone over 56C
[19:40] <ccheney> its amazing what a heatsink can do if not coated in dust :)
[19:47] <Caesar> slangasek: everything in main is supposed to be using upstart jobs now, right?
[19:50] <james_w> no
[19:50] <slangasek> Caesar: I don't think that was ever explicitly the target for lucid; certainly everything in main is a candidate for conversion, but there are some things that are probably too touchy to convert this late
[19:53] <apachelogger> superm1: ping
[19:54]  * sebner waves at apachelogger :)
[19:54]  * apachelogger hugs sebner
[20:31] <superm1> apachelogger, contentless pong
[20:33] <apachelogger> superm1: hey, are you ok with moving bluez-gstreamer from a recommends of the bluetooth package to suggests? ... hence it probably needs to be added to the ubuntu-desktop seed
[20:34] <apachelogger> currently it (along with all of gstreamer) gets pulled in on kubuntu
[20:34] <superm1> sounds fine by me
[20:34] <apachelogger> superm1: ok, are you going to add it to the seed?
[20:34] <persia> May also have to be added to the serveral other gstreamer using flavour seeds.
[20:35] <apachelogger> persia: good point, I better drop a mail somewhere
[20:35] <persia> ubuntu-devel@ seems likely.
[20:35] <persia> Alternately, check the set of tasks that currently apply, and go fiddle the seeds yourself/
[20:36] <apachelogger> ah, I better let the appropriate people do that :)
[20:36] <nxvl> james_w: still around?
[20:36] <apachelogger> superm1: fixed package uploaded
[20:36] <nxvl> james_w: how do i pass '-sa' or an equivalent to bzr bd?
[20:36] <crimsun> nxvl: --
[20:37] <nxvl> crimsun: thnx
[20:37] <crimsun> bzr bd -S -- -sa [..]
[20:42] <crimsun> pitti: help for apport-hookutils references http://docs.python.org/library/apport.hookutils, which is 404
[21:04] <jcole> too much noise in #ubuntu
[21:23] <jp_> hi guys. is there a way to fix lirc on intrepid without making a re install? i just saw that a reinstall fixes problms with it. any ideas???
[21:23] <lifeless> jp_: #ubuntu for support please
[21:24] <jp_> i've been there for 1 hours waiting for an answer, lifeless
[21:24] <jp_> thank you anyway for the reminder
[21:24] <lifeless> you can also try the forums
[21:24] <lifeless> and answers.launchpad.net/ubuntu
[21:25] <jp_> i have a forum post for 1 week with no answer
[21:25] <jp_> thanks for the reminder again, you're so kind lifeless :)
[21:34] <persia> james_w: I've just noticed an interesting case: bug #360590 received a branch link from the package upload import branch after the fix was released.  Is this intentional for tracking, or an artifact of how the upload was structured?
[21:35] <crimsun> slangasek: do you know if using "on mounted MOUNTPOINT=/var/lib" in an upstart job will DTRT, i.e., perform an action if /var/lib is mounted?
[21:36] <slangasek> crimsun: I think that depends on what you think "TRT" is.  You shouldn't use that as a start condition for any job uploaded to Ubuntu
[21:36] <james_w> persia: intentional
[21:36] <slangasek> because /var/lib isn't going to be a separate mount point on 99.999% of systems, so you'll never see that signal
[21:36] <persia> james_w: Nifty.  Do we need to do anything to make sure it happens?
[21:37] <james_w> either upload a package with LP: or use --fixes when using bzr
[21:37] <persia> ah, so the same things we do anyway.  Thanks for the work to make it so transparent.
[21:37] <crimsun> slangasek: might "on mounted MOUNTPOINT=/var" be acceptable?
[21:37] <slangasek> crimsun: what are you trying to accomplish?
[21:38] <crimsun> slangasek: run a job only if /var/lib/alsa is accessible to fix the store race
[21:38] <crimsun> I suppose since in most cases /var isn't separate, /var really wouldn't be correct either
[21:38] <slangasek> you will only get 'mounted' signals for things that are actually mount points.  You can't assume that any mount point other than / is or isn't a separate mount point.
[21:38] <slangasek> you want 'on filesystem' for that
[21:39] <crimsun> slangasek: ok, thanks
[21:39] <slangasek> (what store race?)
[21:40] <crimsun> slangasek: on some system it appears that / is mounted read-only, so alsactl store will fail
[21:41] <slangasek> crimsun: in what job?
[21:41] <slangasek> I only have alsa-mixer-save.conf here, and that only runs on shutdown
[21:41] <crimsun> slangasek: this was karmic's alsa-utils, but it appears to be reproducible in lucid's
[21:41] <crimsun> right, lucid added that job
[21:42] <slangasek> ok, so what job has the bug?
[21:42] <persia> crimsun: Could you stick it in /var/run (exceedingly likely to be mounted separately and early), and copy to /var/lib if it's writable?
[21:42] <crimsun> slangasek: meaning which version? lucid'sl
[21:42] <slangasek> crimsun: no, what *job*?
[21:43] <crimsun> slangasek: alsa-mixer-save
[21:43] <slangasek> crimsun: the only job I have in alsa-utils is one that runs on *shutdown*
[21:43] <crimsun> slangasek: right, that's the job
[21:43] <slangasek> then 'on mounted' and 'on filesystem' have nothing to do with it
[21:43] <crimsun> persia: eek? I don't think that's any better than attempting the store directly.
[21:44] <persia> crimsun: It's only better in terms of error codes without || true :)
[21:45] <slangasek> crimsun: is there a bug number for this?
[21:45] <crimsun> slangasek: https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/366160
[21:48] <slangasek> crimsun: start on starting rc RUNLEVEL=[06]
[21:49] <hacker07_> hey
[21:49] <crimsun> slangasek: great, thanks
[21:50] <hacker07_> i have a question
[21:50] <slangasek> crimsun: that works because what you want is to serialize alsa-mixer-save wrt /etc/rc[06].d/, which is what mounts / ro at shutdown
[21:51] <crimsun> slangasek: excellent, thanks for the explanation
[21:52] <cjwatson> hacker07_: just ask, rather than asking to ask
[21:52] <hacker07_> okay
[21:52] <hacker07_> is there an application in development to change the xsplash theme? or images?
[22:18] <slangasek> ccheney: do you know why OOo wants to pull ttf-sil-gentium-basic into main, and whether we should sub a different font that's already in main for Ubuntu?
[22:20] <slangasek> ccheney: _rene_'s changelog says "for graphite support"
[22:20] <slangasek> but I don't know what that is
[22:20] <ccheney> ah then most likely for graphite which does font support for non-latin 1 based (complicated glyph) languages
[22:21] <ccheney> but afaict it only has this dep in 'openoffice.org' itself which isn't in a seed?
[22:21]  * ccheney greps control to see if it is somewhere else
[22:22] <slangasek> ccheney: everything in main is seeded somewhere
[22:22] <slangasek> why does graphite need this font /specifically/, when we already have other fonts in main that correctly implement glyphs for languages with shaping?
[22:23] <ccheney> the sil gentium font is for the sil graphite library afaict which is the thing that does font support for complicated glyphs (for lack a better explanation)
[22:23] <ccheney> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite
[22:24] <slangasek> ccheney: so is this not a Unicode font?
[22:24] <slangasek> if it is, it should be redundant wrt the other fonts we already have that handle shaping
[22:25] <geser> mathiaz: Hi, are you working on merging mutt?
[22:25] <mathiaz> geser: no
[22:25]  * ccheney still investigating to see what it does exactly
[22:26] <ccheney> actually if i am reading this correctly its by the people who wrote graphite but its not for graphite itself, hmm will have to ask rene what is going on
[22:28] <geser> james_w: have you an idea what those date-versioned branches listed on https://code.edge.launchpad.net/ubuntu/+source/mutt and https://code.edge.launchpad.net/debian/sid/+source/mutt are? left over from the package importer?
[22:28] <james_w> yes I do
[22:29] <ccheney> slangasek: apparently it is an extended latin font as opposed to normal latin font, though i am unsure what that means, still waiting to hear from rene to see if he has any additional insight
[22:29] <slangasek> ccheney: that's not a term with a standard definition in fontland, but anyway I'm almost certain it's redundant with stuff we already have in main if it's Latin
[22:29] <james_w> geser: they are when there are collisions between someone uploading a source package and someone pushing the branch. Currently they are more likely to be bugs though.
[22:29] <slangasek> we have very good coverage of Latin glyphs :)
[22:30] <ccheney> ok, i don't know much about fonts myself so not sure if its better or not
[22:30] <ccheney> ArneGoetje: do you happen to know?
[22:31] <ccheney> slangasek: so is the openoffice.org package seeded to the dvd or something, i didn't realize it was seeded anywhere
[22:31] <ccheney> or just a general 'supported' seed i suppose?
[22:33] <slangasek> ccheney: curiously, I can't actually find what's pulling in the openoffice.org metapackage
[22:33] <slangasek> will dig
[22:33] <slangasek> (I /assumed/ it was seeded, because it shows up as the reason on the component-mismatches report)
[22:35] <ccheney> slangasek: talking to rene it apparently does special graphite things already but more is in the queue
[22:35] <ccheney> http://qa.openoffice.org/issues/show_bug.cgi?id=89682
[22:36] <ccheney> "This font supports various advanced typographic capabilities using the Graphite, OpenType, or AAT font technologies." and goes on to explain some of them (in the URL referenced by the bug report)
[22:39] <slangasek> ccheney: ok; I can't say whether those font features are implemented by other fonts we have in main
[22:40] <ccheney> i somehow doubt they are as the font is written by the same people who wrote the extra feature library (graphite)
[22:40] <ccheney> should i file a MIR bug for it to resolve the issue?
[22:40] <slangasek> ccheney: well, let me see what the archive thinks if I move the openoffice.org binary to universe :)
[22:41] <ccheney> heh ok
[22:41] <slangasek> ccheney: if it pops back up on my radar, I'll let you know
[22:41] <ccheney> ok
[22:41] <slangasek> (but it's probably a bug in the component-mismatches report, not caring about the difference between source and binary packages here)
[22:42] <soren> slangasek: Is there any more information I need to provide for bug 525741?
[22:48] <slangasek> soren: followup question sent to the bug
[22:53] <soren> slangasek: ta
[22:55] <sgnb> does lpia still exist?
[22:56] <slangasek> sgnb: no lpia architecture will be released with lucid
[23:04] <bdrung_> jdstrand: hi
[23:05] <bdrung_> jdstrand: yofrankie upstream devs do not have released an tarball yet. that's why the version contains ~svn. You can find a get-orig-source rule for grepping the source from their svn.
[23:06] <jdstrand> bdrung_: I thought I saw a release note for it though...
[23:06] <bdrung_> jdstrand: not that i am aware of.
[23:10] <jdstrand> bdrung_: I found a reference to it in google's cache and thought there might have been a tarball
[23:11] <bdrung_> jdstrand: link?
[23:11] <jdstrand> http://74.125.93.132/search?q=cache:19uCvkl0NUMJ:www.yofrankie.org/+yofrankie+download&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a
[23:11] <bdrung_> jdstrand: there is yofrankie_1_1b_bge.zip, but that's not the source tarball
[23:12] <jdstrand> yeah..
[23:12] <bdrung_> jdstrand: i extended the makefile for making the generation of the tarball simpler. so he has to run "make dist" and upload the tarball somewhere.
[23:15] <jdstrand> bdrung_: fyi, you have a git Vcs in control but an svn pull
[23:16] <jdstrand> bdrung_: where is their svn?
[23:17] <bdrung_> jdstrand: the svn belongs to upstream, the git is for package (but not yet created) - it will be moved to pkg-games
[23:18] <bdrung_> s/for/for the/
[23:19] <jdstrand> bdrung_: your debina/copyright said you downloaded it from www.yofrankie.org, but you are saying you got it from svn. that should really be somewhere-- this is very hard for me to verify
[23:19] <jdstrand> bdrung_: can you give me an svn url?
[23:19] <jdstrand> bdrung_: I see it in the rules file. nm
[23:20] <bdrung_> jdstrand: the url is in the get-orig-source rule: https://svn.blender.org/svnroot/yofrankie
[23:44] <cjwatson> chrisccoulson: do you have any idea what's going on in https://launchpad.net/~cjwatson/+archive/ppa/+build/1526187/+files/buildlog_ubuntu-lucid-i386.gnome-format_0.1.1-0ubuntu8~ppa1_FAILEDTOBUILD.txt.gz ?  I'm trying to rebuild gnome-format against parted 2.1, and, er, well, vala is not my first language
[23:57] <slangasek> cjwatson: heh, I thought you were making a Tolkien joke
[23:58] <cjwatson> I think I can probably manage Quenya very marginally better than GNOME's Vala, not that that's saying much
[23:58]  * slangasek grins
[23:59] <chrisccoulson> cjwatson - i'm just taking a look now, although i'm not that familiar with vala either ;)