[05:33] <dholbach> good morning
[05:34]  * slangasek waves
[05:35] <dholbach> hi slangasek
[05:35] <lifeless> dholbach: do you have a script to repeat what you say on every channel ? :)
[05:36] <dholbach> no, it's easy enough without a script :)
!
[05:40] <persia> Depends on the client.  Some clients have <up> bound to the channel.  Paste/enter can help.
[05:40] <stgraber> some clients also have /msay that just sends a message to all channels (irssi doesn't)
[05:46] <dholbach> does the "report a bug" menu item work for you guys in intrepid?
[05:47] <dholbach> ok... seems to be generally broken
[05:49] <nxvl> dholbach: you are early today, good morning
[05:50] <nxvl> dholbach: mimi needed to wake up earlier?
[05:50] <dholbach> nxvl: exactly :)
[05:51] <dholbach> nxvl: how are you doing?
[05:51] <nxvl> good
[05:51] <nxvl> it was a good and quiet weekend
[05:51] <nxvl> waiting for news which i expect to get tomorrow morning or the day after it
[05:51] <nxvl> i hope
[06:05] <ion_> stgraber: Haven't tested, but i assume /fore chan /say foo works.
[06:10] <ion_> stgraber: Oh, in fact /fore win foo should work, which i consider almost a bug. IMO the syntax should be /foreach <object> <command> <args> instead of /foreach <object> /<command> <args> where a missing / causes it to send messages.
[08:09] <wolfe> persia: you there?
[08:10] <persia> wolfe: Typically, although I much prefer content with my alerts.
[08:10] <wolfe> persia: oh, sorry :)
[08:10]  * persia waits for content, planning to go back into context soon.
[08:11] <wolfe> persia: if someone were using a sensor for detecting when someone was speaking, what type of sensor and where would it be placed?
[08:11] <wolfe> persia: I'm starting to get in to anitronics >.>
[08:12] <wolfe> *animatronics
[08:12] <wolfe> though mostly for special costumes =]
[08:12] <persia> I'd probably rely on bone conduction for that, placing a sensor just before the ear or just under the ear.
[08:12] <wolfe> hmm
[08:13] <wolfe> I'm thinking about making a kangaroo custome which has a moving jaw and eyes
[08:13] <wolfe> just something cute
[08:13] <wolfe> I'm probably going to make it somewhat complex if I can... like this.. http://www.youtube.com/watch?v=B2u7ekG51to
[08:14] <wolfe> I wonder how much money they spent for the specified 30 second commercial xD
[08:15]  * persia doesn't have the right combination of software to watch youtube, but suspects "bunches" is roughly correct.
[08:15] <ion_> youtube-dl and whatever player you prefer.
[08:15] <wolfe> its a korean commerial of this kangaroo who is selling SENS. With moving eyes, jaw, and ears.
[08:17] <persia> ion_: Actually, there are a wide variety of combinations that work.  However, having said combinations installed tends to cause me to watch videos, which is not something I tend to find to be the best use of my time :)
[08:30] <zver> hello. when somebody fix depends on pgbouncer to postgresql-8.2 in intrepid   ?
[08:33] <persia> zver: Specific tasks like that don't tend to be scheduled.  You might open a bug about it, or wait until someone does it.
[08:34] <zver> persia: ok
[08:45] <ArneGoetje> if we do a Fake-Sync, because the same package has been maintained in parallel in debian and ubuntu, do we need to copy the package history of the ubuntu package into the resulting changelog? or is it not necessary?
[08:47] <yao_ziyuan> i just bought a new Samsung DVD recorder and it can read a data CD well under win xp but not well under ubuntu 8.04 + kde 4.1.
[08:47] <yao_ziyuan> someone told me this could have something to do with the kernel driver
[08:48] <yao_ziyuan> so, is it true that new hardware must wait some time for the linux kernel to catch up?
[08:51] <ArneGoetje> the point is: the original tarball comes as .zip and has been repackaged by two different individuals, once for debian and once for ubuntu and has been maintained in parallel since then.
[08:53] <persia> ArneGoetje: Generally, a fakesync should only happen in the case where we'd like to do a real sync, but the orig.tar.gz differs.
[08:54] <ArneGoetje> persia: that's the case here
[08:54] <persia> Personally, I don't tend to keep Ubuntu packaging information when I do a fakesync, and I tend to use a -Nbuild1 version so that it goes away in the future.
[08:54] <dholbach> persia: what happens if Debian uploads a   -<N+1>?
[08:55] <persia> dholbach: The sync fails, and it gets dumpted into manual merges on MoM.
[08:56] <persia> dholbach: I suppose perhaps using Nubuntu1 means that the flag is raised beforehand, so it's less confusing.
[08:56] <dholbach> yeah, I thought so
[08:58] <ArneGoetje> persia: ok, so use ubuntu1 and drop the old ubuntu changelog and use the debian one instead... ?
[08:58] <RAOF> Then what happens if debian uploads $VER+1-1?
[08:59] <persia> RAOF: Then one needs to request a sync from the archive admins.
[08:59] <persia> ArneGoetje: That sounds right to me.
[08:59] <RAOF> Fair enough.
[08:59] <ArneGoetje> persia: ok, thanks
[09:01] <persia> yao_ziyuan: Sometimes.  It depends on the hardware.  If new hardware is introduced for which there is no support by any existing drivers, someone needs to add it.  As the owner of hardware so affected, you're in an excellent position to do so.
[09:01] <persia> Note that much of the hardware being produced these days adheres to various standards to reduce the driver development effort by the hardware manufacturers, and so is not so affected.
[10:06] <fabbione> hi guys
[10:06] <Simira> morning fabbione
[10:06] <fabbione> hey Simira
[10:07] <Simira> fabbione: how is your family?
[10:07] <fabbione> Simira: pretty good thanks
[10:07] <fabbione> and you?
[10:07] <Simira> fabbione: enjoying life in Cambridge for the weekend
[10:07] <fabbione> Simira: ehhe vacation or work?
[10:07] <Simira> fabbione: your kids, they are 2 and 3 years old now?
[10:08] <fabbione> Simira: nah... 2 and 8 months
[10:08] <Simira> fabbione: vacation, Debian BBQ + some sightseeing
[10:08] <fabbione> Simira: lucky you ;)
[10:08] <Simira> fabbione: sounds lively :)
[10:08] <Simira> fabbione: yup, lucky me
[10:08] <fabbione> Simira: they are two little angels with big red horns ;)
[10:08] <Simira> I can imagine
[10:33] <\sh> hmm...is there any way to download the ubuntu netbook remix somehow? I would like to test it on my aspire
[10:35] <davmor2> \sh: there is no current build if that is what you mean.  You can however install it menually.
[10:35] <\sh> davmor2: you mean "install ubuntu via usb cd, and install the packages fom the remix ppa"
[10:36] <davmor2> \sh: yeap
[10:36] <\sh> ok :) that's easy ,->
[10:37] <davmor2> /sh: there should be an image for intrepid at some point as far as I know just not yet :)
[10:38] <\sh> davmor2: well, I just want to remove this linpus linux on it...looks quite nice, but it's somehow fedora based...
[11:04] <emgent> moin
[11:45] <bigon> could someone have a look at https://bugs.edge.launchpad.net/ubuntu/+source/enchant/+bug/261075 ?
[11:50] <devfil_> bigon: in Debian it is fixed, so a merge should be enough
[11:51] <bigon> devfil_, it will require a merge as there are ubuntu changes made by slangasek
[11:51] <asac> ogra: where do i find warren again?
[11:52] <persia> bigon: devfil_: Although I don't usually advocate this pre-FeatureFreeze, the option so far unmentioneed is to port the specific patch from Debian without a full merge.
[11:53] <ogra> asac, #ltsp but he is on boston time ... and usually hangs out here as well
[11:53] <bigon> persia, yeah of course but the last debian upload only fix this issue
[11:54] <ogra> no idea in what other channels he usually is
[11:54] <asac> ogra: ok thanks. ill try to remember that for later today ;)
[11:57] <ogra> tjaalton, what in hal calls debian-setup-keyboard (i want to do something similar for touchscreens so the calibration can sit in a different place)
[12:09] <ogra> tjaalton, what in hal calls debian-setup-keyboard (i want to do something similar for touchscreens so the calibration can sit in a different place)
[12:10] <ogra> tjaalton, i have http://paste.ubuntu.com/40402/ but no idea how to call it or from where
[12:26] <stefanlsd> Does firefox hang  for anyone else when trying to access   www.axxess.co.za  ?
[12:27] <emgent> stefanlsd: me too
[12:27] <stefanlsd> emgent: thanks. yeah. maybe flash. i've been getting it lots lately.
[12:28] <thorwil> stefanlsd: not here. i have flash-block ...
[12:28] <emgent> true, go via links2 -g
[12:28] <emgent> :)
[12:28] <stefanlsd> thorwil: mm. good idea. think i'll try that :)
[12:28] <ogra> asac, does midbrowser use ubufox anywhere ?
[12:28] <emgent> 100% CPU
[12:28] <emgent> nice..
[12:29] <asac> ogra: it doesnt. why?
[12:29] <asac> is that wanted?
[12:30] <ogra> heh, no
[12:30] <ogra> i'm just cleaning up the current ubuntu.mobile seed (new for intrepid)
[12:30] <ogra> and was dropping FF in favour of MB
[12:30] <asac> good
[12:31] <asac> ogra: is the home applet using xul 1.9 in intrepid?
[12:31] <ogra> no idea, ask the maintainer .. i dont use it anywhere yet
[12:32] <asac> ogra-Q1 <- isnt running the home screen?
[12:32] <asac> what a hoax ;)
[12:32] <ogra> asac, http://people.ubuntu.com/~ogra/ubuntu-mobile-intrepid.png
[12:32] <ogra> thats how my ubuntu-mobile on te Q! looks like atm
[12:33] <ogra> plain gnome, three extra apps
[12:33] <ogra> *Q1
[12:33] <asac> nice
[12:33] <ogra> and settings
[12:33] <asac> ogra: nm 0.7?
[12:33] <ogra> whatever is in ubuntu-desktop :)
[12:34] <asac> ogra: tbird is in the seeds?
[12:34] <asac> good news ;)
[12:34] <asac> wel ... partially good news.
[12:35] <ogra> why partially ?
[12:35] <asac> the bad is that tbird 3 probably wont be able to use system-xul
[12:35] <ogra> meh
[12:35] <asac> because the whole mailnews mess turns out to be too hard to migrate before 3.1
[12:35] <ogra> will we switch before release ?
[12:35] <asac> ogra: unlikely
[12:36] <ogra> well, then i'm fine
[12:36] <asac> i think in intrepid+1 they will have a release
[12:36] <ogra> ubuntu-mobile is a first shot only now
[12:36] <ogra> fine tweaking will be done in intrepid+1 ... for intrepid having it basically usable and not to ugly is enough
[12:45] <tjaalton> ogra: 10-x11-keymap.fdi
[12:46] <tjaalton> ogra: so you'd need to match the device and add the callout
[12:49] <ogra> ah
[12:49]  * ogra will test that later today
[12:50] <tjaalton> ogra: create a new fdi file for evtouch.. that could then be added to the package
[12:54] <dholbach> maybe somebody could give a session at Ubuntu Developer Week about  https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases  ?
[12:55] <ogra> tjaalton, right, but it needs matches for the touchscreen devices as well
[12:56] <tjaalton> ogra: yes
[12:56] <ogra> tjaalton, so it will rather be multiple files ... which i'd still like to see in hal-info to get at least the right drivers (many touchscreens default to "mouse" or "evdev" if hal doesnt know anything about them)
[12:56] <ogra> which simply doesnt work
[12:56] <tjaalton> why multiple files?
[12:57] <ogra> i'd also like to see evtouch in the default selection of input drivers but thats likely something bryce has to decide
[12:57] <ogra> because there are plenty of devices
[12:57] <tjaalton> they can all be in the same file, see synaptics
[12:57] <ogra> with different ways of recognizing them as touchscreens
[12:57] <ogra> hmm, that would become a complicated file
[12:58] <tjaalton> tough :)
[12:58] <ogra> i'd like to find a way to categorize them and have one file per category
[12:58] <persia> tjaalton: There are lots of classes of touchscreens.  Should they really all the the same file?
[12:59] <ogra> i.e. there are the ones with input.mouse capabilities you can only recognize by other info ... then there are some that register as input.touchpad etc
[12:59] <ogra> HW wise thats a big mess
[12:59] <persia> I'd think one file per class of touchscreens would make more sense.
[13:00] <tjaalton> one per driver?
[13:02] <ogra> well, what i said above applied to evtouch alone
[13:02] <tjaalton> right :)
[13:02] <ogra> there are other touchscreens with other drivers (serial ones etc)
[13:02] <tjaalton> and wacom
[13:03] <ogra> right
[13:03] <persia> tjaalton: But even in the evtouch case, there are some that identify themselves as touchscreems, and some that identify themselves as mice.  Can these not also be separate files?
[13:04] <tjaalton> persia: yes they could, but I still don't see why keep them separate
[13:05] <Hobbsee> lifeless: use /ame
[13:05] <Hobbsee> lifeless: it seems to be the standard
[13:05] <lifeless> Hobbsee: ?!
[13:05] <tjaalton> persia: not that it would be a huge issue to me.. the fdi files will eventually be upstream (like synaptics has)
[13:06] <Hobbsee> lifeless: earlier you asked about a script to broadcast the same thing on multiple channels :)
[13:06] <lifeless> Hobbsee: no
[13:06] <Hobbsee> well, commented on it
[13:07] <lifeless> you misread the intent of my question :)
[13:07] <Hobbsee> or reinterpretted it.  but yes :)
[14:01] <Adri2000> amsn srus for dapper and gutsy are tested and can be copied to -updates now, bug #243722
[14:36] <huats> I am not very familiar with python-support, so if someone is, I'd like to ask a few questions
[14:37] <persia> huats: You may find #ubuntu-motu to be a more useful forum for that sort of question.
[14:37] <huats> :)
[14:37] <huats> ok
[14:37] <huats> thanks persia
[14:44] <soren> When does slangasek usually show up?
[14:47] <pwnguin> as soon as the germans leave ;)
[14:48] <cody-somerville> soren, thats a difficult one to answer... usually he just doesn't leave at all :P
[14:48] <pwnguin> those IRC stat generators could probably answer such a question
[14:48] <persia> soren: He's UTC-7, so probably not for a few hours yet.
[14:49] <soren> persia: Cool. Thanks.
[14:49] <persia> pwnguin: Those aren't necessarily accurate.  For quite a while I had about even stats in all timezones in one channel.
[14:50] <zul> soren: soon probably :)
[14:52] <asac> geser: are you openvpn master? look at bug 260291
[14:53] <asac> appars to have regressed with one of the last openvpn uploads
[15:02] <zul> asac: what happened?
[15:11] <zul> asac: : ping *sigh* itll be fixed today
[15:16] <geser> asac: sorry no, I'm not a openvpn master
[15:31] <asac> zul: ?
[15:31] <asac> geser: ok thanks. just found your name in the changelog there ;)
[15:31] <zul> asac: openvpn
[15:31] <asac> zul: oh. you know that bug?
[15:32] <zul> asac: yeah its in the NEWS file
[15:32] <zul> im modifying the init script so its backwards compatible
[15:33] <asac> zul: rock. can you close that bug in the upload?
[15:33] <zul> asac: yep
[15:33] <asac> ill close the network-manager-openvpn task as invalid then
[15:33] <asac> thanks
[15:44] <zul> asac: fix has been uploaded
[16:06] <LaserJock> dholbach: I'll have a look at the matplotlib merge (I've been communicating with upstream on it)
[16:07] <dholbach> LaserJock: excellent
[16:07] <dholbach> gracias
[16:08] <LaserJock> Bitte schön
[17:06] <slangasek> soren: much later than 6:45 :-)
[17:10] <soren> slangasek: Slacker.
[17:10] <soren> :p
[17:10] <soren> :)
[17:44] <bazaar> hi. why does gettext output a standard char * pointer, and not wchar_t * -- shouldn't the output be wide characters as it some unicode/utf stuff?
[17:47] <slangasek> no, char * is the standard type for strings in Unix
[17:47] <slangasek> and UTF-8 is not a wchar representation
[17:54] <ion_> Yeah, UTF-8 is an 8-bit encoding.
[17:55] <bazaar> so do chinese characters fit in a char * ?
[17:55] <bazaar> 'how do ...
[17:58] <persia> bazaar: A sequence of bytes, with the most significant bits being a flag for the renderers.  Documentation on the UTF-8 encoding may be helpful.
[18:02] <soren> Err.... Can someone explain what I need to do to bug 251480 to get it listed on https://bugs.edge.launchpad.net/ubuntu/+source/kvm?
[18:07] <Laney> soren: It probably doesn't show as it's Fix Released
[18:07] <soren> Laney: Except the hardy task, which is "confirmed".
[18:08] <Laney> soren: Yes, but the +source/kvm page only shows Ubuntu tasks, AFAICS
[18:08] <Laney> soren: It does show at https://bugs.launchpad.net/ubuntu/hardy/+source/kvm
[18:08] <LaserJock> yeah
[18:09] <soren> Well, i guess I can add an intrepid task, set that to fix released, and set the "general" state to "Confirmed".
[18:09] <LaserJock> the plain bugs listing doesn't show release targeted bugs, you have to go to the release specific bug listing
[18:10] <soren> Mky
[18:10] <soren> mkay, even.
[18:10] <soren> Yeah, that didn't help. :(
[18:14] <LaserJock> soren: now you're makin' a mess :-)
[18:15] <soren> Yeah :(
[18:15]  * soren goes and stands in the corner
[18:15] <slangasek> bugs that are fixed in the latest dev release are not expected to show up under ubuntu/+source/
[18:16] <slangasek> only under ubuntu/$targeted_release/+source
[18:17] <soren> That seems suboptimal. It'll usually be fixed in the latest dev release first. I don't want it off my radar until it's fixed everywhere, I think.
[18:18] <LaserJock> although I would think one would assume that the ubuntu/+source list would give all open bugs and that you'd use ubuntu/<devel release>/+source if you wanted to weed out others
[18:19] <geser> it's known as bug 121602
[18:35] <soren> geser: Thanks.
[19:22] <kees> slangasek: okay for me to move from md5 to sha512 in pam?
[19:53] <tseliot> superm1: did you have a look at the code I wrote for you?
[19:54] <superm1> tseliot, yeah it looked good.  it is going to be in the next -common upload
[19:54] <superm1> thanks
[19:54] <tseliot> superm1: great :-)
[19:55] <slangasek> kees: well, no objections on my side :)
[20:02] <bryce> tseliot, superm1: I spoke with ATI about the fglrx/xserver 1.5 issue.
[20:03] <bryce> so they're aware of it and are also anxious to find a solution.  I presented several options and am waiting to hear back.
[20:03] <superm1> bryce, what options did you present to them?
[20:04] <superm1> of course the most ideal is that they just get support for xorg 1.5 :)
[20:04] <bryce> a) revert the change that removed the symbols (which sounds like a gordian knot)
[20:04] <tseliot> bryce: shall we try to reintroduce the AllocatePrivateIndex or whatever it's called in the xserver?
[20:04] <bryce> b) put in a stub version of the symbol (which we'd need their assistance with)
[20:04] <bryce> c) a hotfix version from them that doesn't use the symbol
[20:05] <superm1> yeah, i don't think (a) is a feasible solution at this point
[20:05] <superm1> especially with how big of a change that is
[20:05] <jcristau> b doesn't sound like a feasible solution to me
[20:05] <bryce> d) SRU the version with 1.5 support post-release
[20:08] <bryce> jcristau: yeah I indicated (c) would be the best option.  I don't know what miZeroLineScreenIndex does exactly but assume a stubbed function would cause breakage elsewhere.
[20:08] <jcristau> bryce: that symbol is just the tip of the iceberg
[20:08] <jcristau> bryce: there are multiple abi and api changes between 1.4 and 1.5
[20:09] <bryce> (d) I think is a bad option because all fglrx users would break on upgrade.
[20:09] <superm1> not to mention that we don't have all the other integration pieces (eg jockey) fully tested with the new way of doing things
[20:10] <bryce> one option I didn't present but that I guess also belongs on the list is e) reverting to xserver 1.4
[20:10] <jcristau> bryce: at least the xace-selinux work, and pci-rework
[20:11] <materic> Hi i need a help for running a just compiled code. can i address the question?
[20:11] <tseliot> bryce: miZeroLineScreenIndex is not the only problem. I have tried to fix that and I got an error about AllocateScreenPrivateIndex. AFAIK miAllocateGCPrivateIndex is used in X now.
[20:11] <bryce> materic: wrong channel -> you want #ubuntu
[20:11] <tjaalton> bryce: you forgot to add a smiley ;)
[20:12] <bryce> :-D
[20:12] <bryce> morning tjaalton
[20:12] <tjaalton> hi all
[20:12] <bryce> fwiw Intel also wishes us to revert back to 1.4, but I think the issue they are seeing is just a normal bug we can probably solve in the next 1-2 months
[20:12] <jcristau> tseliot: right, the devprivates rework is a major api/abi change
[20:13] <bryce> another option I did not mention is to just drop -fglrx as a supported driver
[20:13] <tseliot> bryce: that would certainly solve our problem ;)
[20:13] <bryce> anyway, if anyone else has more ideas on options I'm all ears, that seems to be the scope though.
[20:13] <superm1> would reverting back to 1.4 mean that newer drivers have to be reverted too?
[20:13] <tjaalton> bryce: intel? what bug exactly?
[20:13] <bryce> superm1: I'd assume we'd have a big mess on our hands
[20:14] <jcristau> all that because ati can't get their act together?
[20:14] <bryce> tjaalton: unfortunately they filed it private and didn't subscribe me, so I only have a vague description to go by
[20:14] <ramses-sv> run active_notice
[20:14] <tjaalton> bryce: ok
[20:14] <bryce> tjaalton: it's with a newer / unreleased chipset so I suspect it's just a normal hw support issue, nothing earth shattering
[20:15] <tjaalton> bryce: ok, at least our current driver doesn't support Xv for G45, since one of the patches disable textured video
[20:16] <tjaalton> and the chip doesn't support anything else
[20:18] <tjaalton> also, we have 2.4.0 while there is 2.4.1 ready to be merged
[20:18]  * bryce nods
[20:18] <bryce> hey, any idea of when xserver 1.5 will be released?
[20:18] <tjaalton> when mesa 7.1 is released
[20:19] <tjaalton> at least GEM is dropped from it so there's no need for a new libdrm as well
[20:19] <jcristau> mesa 7.1 should come this week, according to brian
[20:20] <tjaalton> so it seems
[20:20] <tseliot> bryce: in any case I think we should prevent dist-upgrades from crashing X because of the 2 NVIDIA legacy drivers and of the ATI driver.
[20:20] <elmo> bryce: do you know why we still ship i855-crt in main?
[20:20] <tjaalton> tseliot: that's doable by "blacklisting" those drivers, and let them use nv/ati instead
[20:21] <tjaalton> after upgrade
[20:21] <tseliot> tjaalton: ok but if a driver is set in the xorg.conf you can blacklist the kernel module
[20:22] <bryce> elmo: no, I'm not familiar with that package, why do you ask?
[20:22] <tseliot> tjaalton: but that wouldn't prevent X from crashing would it?
[20:23] <tjaalton> tseliot: no, but a forced dexconf run would
[20:23] <elmo> bryce: I filed a bug on it, years ago, saying "we should either demote/remove this package, or actually apply the patches people send for it", and people keep pinging me about the bug
[20:23] <elmo> I'm pretty sure it's entirely obsoleted by xrandr
[20:24] <elmo> but I'm also guessing ;-)
[20:24] <bryce> elmo: could be
[20:24] <tjaalton> shocking, it is still in main
[20:24] <bryce> elmo: I don't recognize it as a package on the ubuntu-x package list; maybe it's just cruft?
[20:24] <verwilst> hm, i just made a deb but it installs stuff in /usr/usr/lib/...
[20:24] <elmo> bryce: I think it is, yeah.  if you guys don't want it, no one else will :)
[20:25] <tjaalton> bryce: should be removed. no code changes since 01 Sep 2004 :)
[20:25] <tseliot> tjaalton: ok, so we would have to detect the card and see if it's not supported by a driver which works with X and force a dexconf if required, since we don't want to break nvidia-glx-177 and 173
[20:25] <superm1> tjaalton, tseliot alternatively just not offer dist-upgrades if any of those packages that will cause breakage are present, at least until sorted out
[20:26] <bryce> yeah, poking through it, it looks like a ubuntu-only package that has become direly obsolete.  I'll file a removal request
[20:26] <bryce> elmo: thanks
[20:27] <elmo> bryce: np, thank you :)
[20:27] <tseliot> superm1: yes, that's an option, unless you're doing the dist-upgrade from the command line
[20:28] <tjaalton> cmdline is hard.. those people will notice when/why X doesn't work ;)
[20:28] <tseliot> superm1, tjaalton: maybe we could reuse nvidia-common for such hardware check
[20:28] <bryce> is there any reason we should keep i855-crt in universe, versus removing it entirely?
[20:29] <bryce> since we're not even shipping -i810 anymore I'm guessing it'd be useless in universe anyway
[20:29] <tseliot> tjaalton: very often do they use the command line and do things they shouldn't
[20:30] <tjaalton> bryce: no, ditch it. no changes upstream since May 2004
[20:30]  * tseliot > bbl
[20:34] <bryce> ok, lp #261259
[20:36] <bryce> hm, wonder if there's any other ancient X cruft that escaped our cleanup
[20:37] <tjaalton> maybe if there's a list of packages that are only in ubuntu. should be pretty easy to check
[20:38] <bryce> yeah was just trolling around for that.  anyone know if there is such a list?
[20:47] <kees> slangasek: if I change common-password, what do I need to do to the .md5sums file?
[20:48] <LaserJock> bryce: http://qa.ubuntuwire.com/multidistrotools/all.html#notinA
[20:51] <bryce> LaserJock: aha thanks
[20:54] <bryce> lotta kde stuff there...
[20:57] <ogra> we're ahead wrt KDE
[20:57] <bryce> "p0rn-comfort" ??
[20:58] <Riddell> debian isn't changing to KDE 4 until after their next release
[21:00] <Riddell> and today I discovered Mithrandir and a large proportion of Debian punting along the river Cam which is no way to get a release out of time :)
[21:00] <Riddell> s/of/on/
[21:01] <LaserJock> lol
[21:02] <bryce> ok, I didn't spot any additional X cruft in that list.  At least, nothing we don't already know about
[21:03] <kees> bryce: ... hunh.  that appears to either predate the original-maintainer stuff (and hasn't been updated since original upload) or has been long-since removed from Debian.
[21:05] <slangasek> kees: nothing at all \o/
[21:05] <kees> slangasek: I like the sound of that.  :)
[21:12] <kees> slangasek: should I renumber the current pam bzr to ubuntu5 (instead of 4.1) add my md5->sha512 change and upload the results, or is that change not something you want in intrepid?
[21:13] <slangasek> kees: er, yes, renumber to ubuntu5, sorry; as for uploading, I have more changes pending today
[21:13] <slangasek> kees: but I don't know of any reason we can't switch from md5 to sha512 for intrepid
[21:14] <slangasek> I'm relying on your judgement that this is better for security :)
[21:15] <kees> I'm just trying to think ahead for the next LTS.
[21:16] <kees> slangasek: I've committed my changes to bzr so you can roll them into your pending changes for the next upload.
[21:16] <slangasek> ok
[21:18] <slangasek> kees: oh, I guess I read what I wanted to above rather than what you said; yeah, we need to do something wrt the change to the common-password template, but the code's not there yet to do this, so you needn't worry about it anyway :)
[21:19] <slangasek> that'll push back the upload a bit, though; need to have that sorted before we go changing the template further
[21:20] <kees> slangasek: okay -- I have yet to really understand the per-package profile stuff you've made.  I've only poked around the edges so far.
[22:19] <mathiaz> slangasek: kees has run into an issue when installing slapd in non-interactive mode and a debconf level of critical - the admin password for cn=config is not generated
[22:20] <mathiaz> slangasek: kees suggested to use a random password for cn=config if debconf is unable to prompt for the password
[22:20] <slangasek> mathiaz: er, and then how will the user find out that password, or be able to change it?
[22:20] <mathiaz> slangasek: well - the other option is to not put a password
[22:21] <kees> slangasek: if the admin is crazy enough to have their debconf set that high, shouldn't it be their problem?  :)
[22:21] <slangasek> why is either of these options better than failing when using the noninteractive frontend? :)
[22:21] <kees> slangasek: because i can't automatically install slapd for testing in intrepid now.
[22:21] <slangasek> kees: preseeding?
[22:22] <kees> slangasek: I shouldn't have to know that in advance to have an installable package.
[22:22] <slangasek> I think leaving the system with no way to administer the config is some pretty bad foot-shooting
[22:22] <slangasek> you don't have to know that in advance unless you insist on using the non-interactive frontend
[22:22] <kees> I'm using the non-interactive frontend.  ;)
[22:22] <kees> there should be a viable default.
[22:23] <slangasek> there *isn't* a viable default
[22:23]  * kees holds his face
[22:23] <slangasek> the default you're proposing leaves the user without a viable server, because it can't be administered
[22:24] <kees> okay, so, prior to slapd installs, I just need to run "echo set slapd/internal/adminpw asdfasdf | debconf-communicate" ?
[22:24] <slangasek> yes
[22:24] <mathiaz> kees: well - you have to compute a proper string for slapd/internal/adminpw
[22:25] <slangasek> mathiaz: he should be able to set the cleartext question, instead?
[22:25] <slangasek> (which is the one I meant to say 'yes' to)
[22:25] <mathiaz> slangasek: yes -
[22:26] <mathiaz> kees: you can set the cleartext password with slapd/cfgpassword1 and slapd/cfgpassword2
[22:26] <mathiaz> kees: ^^ these are the ones for the cn=config password
[22:26] <kees> mathiaz: okay, well, I guess my main issue is I want to get the test-openldap.py regression test to pass again.  :)
[22:27] <mathiaz> kees: ok - so you'd probably have to add support for slapd.d/
[22:27] <mathiaz> kees: slapd.conf is no longer the default in intrepid
[22:28] <slangasek> well, slapd can be /made/ to run with slapd.conf, you just don't get any of the package management support then
[22:29] <kees> hrm, okay, well, I guess I will leave this alone for a bit -- I need to study a lot of openldap before I can dig in.  perhaps jdstrand will have some time to poke at it (he wrote the tests originally)
[22:29] <mathiaz> slangasek: on a related note, I've managed to build the nss overlay
[22:29] <mathiaz> slangasek: so I'm planning to ship the nss overlay in the slapd package directly
[22:30] <slangasek> sounds reasonable
[22:30] <jdstrand> I'd argue that people updating the package should be using the regression tests ;)
[22:30] <kees> jdstrand: I agree.  ;)
[22:30] <slangasek> then you'd better put them in the package instead of in an external repo... :)
[22:31] <kees> slangasek: it can't sanely run from a build-test
[22:31] <slangasek> hmm, why not?
[22:31] <jdstrand> slangasek: not really an option for these tests
[22:31] <jdstrand> generally, the qa-regression-testing scripts need external tools, install things in the default locations, etc
[22:31] <kees> slangasek: it requires many additional packages, and performs a full (destructive) test of many many ldap functions.
[22:32] <slangasek> additional packages --> Build-Depends
[22:32] <jdstrand> slangasek: they are not just tests for binaries, bbut entire package tests
[22:32] <slangasek> testing ldap functions -- upstream already has a test suite that does quite a bit of LDAP destruction :)
[22:32] <slangasek> but ok, if you want a full-package test, that doesn't help
[22:33] <jdstrand> slangasek: we change backends, sasl, and loads of other stuff
[22:33] <jdstrand> even added some kerberos stuff
[22:33] <slangasek> well, all that should be testable in a build tree
[22:33] <slangasek> hmm, maybe not kerberos :)
[22:34] <slangasek> but backend testing is already in the upstream testsuite
[22:34] <jdstrand> slangasek: perhaps, but I don't think the security team (who has been doing most of the work on these) has the resources to update the packages-- not to mention, adding the tests to intrepid's build doesn't help when we want to test on dapper
[22:35]  * slangasek nods
[22:36] <kees> well, basic stuff seems to work, so I've uploaded a new openldap with PIE enabled...
[22:37] <jdstrand> kees: what doesn't work anymore?
[22:37] <YokoZar> Hmm, I'm getting hangs at login now but it's NOT the snd_pcsp issue...something else
[22:37] <kees> jdstrand: test-openldap.py on intrepid
[22:37] <jdstrand> kees: right, I meant what tests fail?
[22:37] <kees> jdstrand: yes.  ;)
[22:37] <jdstrand> oh-- all of them
[22:37] <jdstrand> cool
[22:37] <kees> jdstrand: it can't even figure out where the daemons are.
[22:37] <jdstrand> nifty
[22:38] <kees> jdstrand: so I've relegated this to the "post-freeze bug fixing" part of my TODO list
[22:38] <jdstrand> I can say it was working the last time I touched it :)
[22:38] <jdstrand> but that was before all the cnconfig work
[22:38] <kees> right, that seems to be the "problem".
[22:39] <jdstrand> kees: oh, well yes-- if we are pure cnconfig, then all our on-the-fly slapd.conf will have to be migrated
[22:39] <jdstrand> (and I haven't done that either)
[22:39]  * kees nods
[22:39]  * jdstrand is finally up to speed
[22:40] <dupondje> mysql got broken in AMD64
[22:42] <mathiaz> dupondje: which bug are you refering to ?
[22:42] <dupondje> https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bug/261066
[22:48] <dupondje> ok got it fixxed
[22:49] <dupondje> mysq-common 5.0.67 gets installed on AMD64 pc
[22:49] <dupondje> but the mysql-server & mysql-client are still old versions (because build failed ...)
[23:05] <kees> infinity: is this a result of the sbuild patch you made?
[23:05] <kees> linux-kernel-headers: installed (negative dependency) (bad version ~*=PROVIDED=*= <= 2.5.999-test7-bk-17)
[23:06] <kees> (while compiling dovecot)
[23:14] <kees> infinity: hrm, I guess not.