[03:58] <jp--> hi guys. can I compile/downgrade the kernel using apt-get install linux-source and then copying to /usr/src a copy downloaded from kernel.org and then compile it and make deb packages?
[04:04]  * persia idly wonders if make-kpkg works properly for Ubuntu
[06:39] <billy12> Im sorry to bother ya'll, but dose any know what the BIN file name for "Hardware Drives" is in 9.10?
[08:15] <czajkowski>  /c
[09:00] <cjwatson> jp--: why would you do anything at all in /usr/src? :-)  Even Linus has been telling people to stop compiling kernels in there for a good decade now ...
[09:01] <jp--> cjwatson, anyway, I didn't finally compile it. Just switched to a better version of ubuntu :) thanks for replying though!
[09:14] <cjwatson> jp--: to answer your question, the upstream kernel has 'make deb' targets I believe, but of course on your head be it - you'll have to be careful about the config.  I would start from 'apt-get source linux' rather than 'sudo apt-get install linux-source', if I hadn't delegated all my personal kernel-building to my distribution years ago :-)
[09:15] <jp--> :) hehe thanks
[09:49] <sebner> cjwatson: thanks for merging dpkg!
[09:58] <jp--> cjwatson, I need your help, if you can.
[09:58] <jp--> I play this using sudo: sudo aplay /usr/share/sounds/alsa/Front_Center.wav
[09:58] <jp--> but when I try to do it on a normal user, it says: audio open error: No such device
[09:58] <jp--> any ideas?
[10:01] <jp--> ouch. user groups.
[11:46] <ari-tczew> hello ubuntu-main-sponsors, please sponsor fake sync @ bug 511448 thanks
[14:03] <bdrung> pitti: i have some questions how the batch sync works (and how we can implement the XfakesyncY)
[17:36] <kees> alright, who broke apache
[17:47] <kees> zul: mysql-cluster-7.0 breaks libmysqlclient-dev
[17:49] <kees> mysql-dfsg-5.1 and mysql-cluster-7.0 provide libmysqlclient16 libmysqlclient16-dev but the latter is version 7, which breaks mysql-dfsg-5.1's libmysqlclient-dev
[17:54] <geser> and the problem is only visible on AMD64 currently as the i386 build of mysql-cluster-7.0 FTBFS
[17:55] <kees> geser: ah, good call, I was wondering why I'd only seen the amd64 failure emails
[17:55] <kees> I've opened bug 521815
[18:25] <dupondje> asac: <window id="main-window" when starting firefox since last update ...
[18:25] <asac> dupondje: new lang packs?
[18:25] <asac> ArneGoetje: ^^
[18:25] <asac> dupondje: what locale are you running?
[18:25] <dupondje> dutch (nl-BE)
[18:25] <asac> maybe hop into #ubuntu-mozillateam
[18:25] <dupondje> running it with LANG=C firefox it works
[18:26] <asac> dupondje: what locale are you using?
[18:26] <dupondje> dutch (nl-BE)
[18:26] <asac> ok ... i am updating now ... let me see if its also for -de
[18:27] <asac> takes a bit. stay tuned
[20:06] <dupondje> pitti: you there ?
[20:07]  * persia suspects not, given the hour and day of week
[20:08] <dupondje> seems like language-pack-nl(-base) is broken :(
[20:08] <persia> Ugh.
[20:09] <dupondje> language-pack-nl seems to provide a broken mozilla language file
[20:09] <persia> Best bet is to file a bug.
[20:10] <dupondje> it overwrites the mozilla language file of language-pack-nl-base
[20:10] <dupondje> i'll do :)
[20:17] <dupondje> https://bugs.launchpad.net/ubuntu/+source/language-pack-nl/+bug/521876
[20:17] <dupondje> its quite critical imo :)
[20:17] <persia> Probably only "high" because it only affects nl
[20:17] <persia> But definitely in need of fixing soon.
[20:18] <dupondje> it affects some more languages it seems
[20:18] <dupondje> mozilla doesn't run anymore because of it :)
[20:38] <zul> kees: on it
[20:49] <slangasek> zul: what's your idea for fixing this?
[20:50] <zul> slangasek: i just removed it from mysql-cluster-7 for now
[20:51] <slangasek> zul: that doesn't solve the problem in the archive, though, since it's already been accepted on amd64 and taken over the binary package
[20:51] <IDWMaster> I found a workaround for the DEB upload problem I had yesterday. It is intermittent because Mono doesn't produce Debian-friendly makefiles.
[20:51] <IDWMaster> I fixed it by manually editing the makefiles.
[20:51] <zul> slangasek: ok then how do you suggest i fix it?
[20:53] <slangasek> zul: if I had a good solution, I'd have mentioned it already (or done it) :)
[20:53] <zul> slangasek: heh
[20:53] <slangasek> zul: I'm inquiring whether we can get soyuz to accept downgrading the binaries in lucid on a one-off basis
[20:53] <slangasek> and considering whether I should yank the broken binaries that have already been uploaded
[20:54] <slangasek> in fact, I'm reasonably convinced that the latter is sane anyway
[20:55] <slangasek> (it will break debootstrapping and CD builds and various package builds that are already broken, but will limit the spread of the damage)
[20:55] <zul> frig...sorry about this
[20:56] <kamalmostafa> I'm still having trouble with requestsync.  slangasek, you reported that this worked for you in Lucid but I get the same problem with Lucid or Karmic.   Any more advice?...
[20:56] <kamalmostafa>    $  requestsync --lp -d unstable -s clxclient lucid
[20:56] <kamalmostafa>    E: Did not retrieve any changelog entries. Was the package recently uploaded? (check http://packages.debian.org/changelogs/)
[20:57] <slangasek> oh, this is odd; the source package says it ships libmysqlclient16-dev, but that's still at version 5.1.41-3ubuntu4 in the archive
[20:57] <slangasek> kamalmostafa: DNS issue or web proxy that's preventing requestsync from downloading the changelog entries?
[20:58] <slangasek> ah, because libmysqlclient16-dev is Arch: all and i386 FTBFS, heh
[21:01] <kamalmostafa> slangasek: I don't use a web proxy, and I can see the updated changelog entry fine in my web browser http://packages.debian.org/changelogs/pool/main/c/clxclient/current/changelog so I don't think it could be a DNS issue.   I had wondered if perhaps requestsync itself was somehow caching it, but I get the same problem in a fresh VM of Lucid alpha2 where it couldn't possibly be cached.   I'm bewildered.  Perhaps I should file jus
[21:02] <slangasek> kamalmostafa: you cut off at "should file jus"
[21:02] <kamalmostafa> Perhaps I should file just file a bug?
[21:02] <slangasek> but I really don't know what's causing the problem for you, sorry.  The next step would probably be to trace requestsync and see what it's doing
[21:02] <slangasek> yes, filing a bug probably makes sense
[21:03] <lifeless> kamalmostafa: uhm
[21:04] <lifeless> kamalmostafa: I'd have a look at tcpdump / wireshark and see what actual request/response is going over the wire
[21:04] <lifeless> that may well help you determine whether its environmental (and not something a software change will help) or a bug
[21:04] <kamalmostafa> slangasek: I'm no python-guru, but I'd be happy to add whatever the equivalent of /bin/sh's "set -x" to the top of requestsync, to collect more info for the bugreport.
[21:06] <kamalmostafa> lifeless: slangasek can't reproduce the problem, so I do think its likely to be something different about my env -- hence hoping to sort it out locally before filing a bug -- thanks for the advice, I'll see what I can determine.
[21:15] <slangasek> zul: best idea I've come up with so far, which doesn't involve hard-resetting the package version number in soyuz, is to have mysql-dfsg-5.1 manually build the libmysqlclient16 package with a version number of 7.0.9-really-$curver
[21:15] <slangasek> zul: that can be scripted in the build, and the delta cleans itself up in the future when libmysqlclient16 really does advance past version 7.09
[21:17] <slangasek> the only caveat is that, if libmysqlclient16 7.0.x adds new symbols, the shlibs need to have a minimum version strictly greater than 7.0.9-really-5.*
[21:17] <zul> slangasek: k looking
[21:18] <slangasek> if you get something together that you think does the job, I'm happy to review it before upload
[21:18] <zul> k
[21:18] <zul> slangasek: so you are just changing the package name arent you?
[21:18] <slangasek> no, the version number
[21:19] <slangasek> dpkg-gencontrol can take an option to force override the version number of the binary package
[21:19] <slangasek> (which can be passed via dh_gencontrol, if that's how you invoke dpkg-gencontrol)
[21:24] <kees> zul: we should try to fix this in soyuz if we can; I'd like to avoid a XreallyY in binary packages if at all possible.
[21:26] <zul> either or
[21:28] <slangasek> right - I think it's good to have the package ready to go in case we decide that's the solution, but please don't upload it until we've exhausted other possibilities w/ soyuz
[21:38] <geser> kamalmostafa: have you checked if the changelog on PTS for that package is uptodate?
[21:39] <slangasek> geser: running the same command here, I don't get this error
[21:39] <kamalmostafa> geser: Yes, it does appear up to date (includes 3.6.1-1.1):  http://packages.debian.org/changelogs/pool/main/c/clxclient/current/changelog
[21:39] <geser> ok, as that caused some trouble in the past days as the changelogs didn't get updated
[21:41] <zul> slangasek: couldnt we use makeshlibs as well?
[21:42] <kamalmostafa> slangasek, geser: bug 521904
[21:44] <slangasek> zul: use it for what?
[21:45] <zul> slangasek: nm i was just reading the man page
[22:07] <zul> slangasek: i was thinking something like this http://paste.ubuntu.com/376472/ but i have go feed my son so ill be back later thanks for you help
[22:07] <geser> kamalmostafa: good news, I can reproduce it
[22:07] <kamalmostafa> geser: really!  Well, that is good news!
[22:09] <geser> kamalmostafa: the debian LP mirror didn't sync the new version yet, and LP still believes that 3.6.1-1 is the most recent version
[22:09] <slangasek> zul: aren't there other calls to dh_gencontrol already in the rules?  I would expect 'dh_gencontrol -Nlibmysqlclient16; dh_gencontrol -plibmysqlclient16 -v$version' to be sufficient
[22:09] <geser> I should make the error message more useful
[22:09] <slangasek> zul: also, you shouldn't hard-code the value of the -v option in rules, it should be derived from debian/changelog (it needs to automatically increment with each package upload)
[22:10] <zul> slangasek: ok ill fix when I get back
[22:10] <kamalmostafa> geser: Oh, okay, so is this the same problem I keep having with "bzr branch" not yielding the latest version then?
[22:10] <slangasek> zul: ok - my apologies if lvm2 wasn't using debhelper, I didn't actually look at it before pointing to it as an example (it's hard to even come up with any examples of this)
[22:10] <kamalmostafa> geser: and how is it that slangasek doesn't also experience the problem?
[22:11] <geser> kamalmostafa: no, as the package branches are independent of the LP mirror
[22:11] <slangasek> apparently I have REQUESTSYNC_MAGIC=1 set in my environment ;)
[22:12] <geser> kamalmostafa: slangasek didn't use --lp
[22:12] <slangasek> yes, I did
[22:12] <kamalmostafa> geser: and actually, I can reproduce the problem with or with --lp.
[22:12] <slangasek> I was trying to reproduce his problem, and copied his commandline verbatim
[22:13] <geser> hmm
[22:13] <kamalmostafa> No, I take that back.  I can **no longer** reproduce the problem without --lp but I certainly could 5 days ago.
[22:13] <geser> with --lp I can reproduce it, without --lp it works here (I've an editor open with the changelog entry)
[22:14] <kamalmostafa> I remembered that --lp versus no --lp was the solution to my previous requestsync problem, so it was the first thing I tried.
[22:14] <geser> I don't know when exactly the changelogs get fixed but they weren't up-to-date in the recent days
[22:14] <slangasek> oh, y'know what
[22:15] <slangasek> $ requestsync --lp -d unstable -s clxclient lucid
[22:15] <slangasek> Changes have been made to the package in Ubuntu.
[22:15] <slangasek> Please edit the report and give an explanation.
[22:15] <slangasek> Not saving the report file will abort the request.
[22:15] <slangasek> Press [Enter] to continue. Press [Ctrl-C] to abort now.
[22:15] <slangasek> kamalmostafa's output didn't include that message, so I assumed I couldn't reproduce the bug
[22:15] <slangasek> but if I hit enter, I get the error
[22:16] <kamalmostafa> Ah... no REQUESTSYNC_MAGIC after all then?  ;-)  glad of that at least!
[22:20] <kamalmostafa> geser: I will leave bug 521904 to you then, as a "make the error message more useful" request, yes?  Okay if I proceed with my clxclient request or will you need it left as is?
[22:20] <geser> kamalmostafa: I will as the soyuz guys why the LP mirror is not up-to-date for clxclient
[22:25] <kamalmostafa> geser, slangasek: thanks for all the help sorting this one.
[22:34] <geser> slangasek, zul: looking at the new FTBFS log for mysql-cluster-7.0: doesn't it now need to build-depend on libmysqlclient16 to let dpkg-shlibdeps succeed? (once this got resolved)
[23:11] <dutchie> hi, apologies if this is the wrong place, but would it be an enormous pain to sync texlive 2009 from debian testing? It seems a bit odd to be shipping 2007 in a distro released in 2010
[23:12] <lifeless> dutchie: see the ubuntu wiki for developer docs; you want https://wiki.ubuntu.com/SyncRequestProcess
[23:12] <dutchie> saw that, it looks quite scary
[23:13] <geser> dutchie: lucid will have TeXLive 2009
[23:13] <dutchie> geser: ah, sweet
[23:13] <dutchie> thanks
[23:14] <lifeless> dutchie: that is however the thing to check; irc is the wrong place ;)
[23:14] <dutchie> lifeless: notice I didn't ask "Please sync it", I asked "Would it be a pain to sync it"
[23:15] <dutchie> if someone had come out and said "no, and here are reasons x, y and z", I would have said "Oh, OK, I won't bother going through the process"
[23:16] <dutchie> if nothing had happened, I would have gone ahead and done it
[23:16] <dutchie> but, as it is, I don't have to care
[23:16] <lifeless> sorry for misjudging the request
[23:16] <dutchie> I probably didn't quite make it clear enough
[23:16] <lifeless> we get a fair number of 'please do x' from folk that haven't looked at all
[23:16] <dutchie> I'm sure you do