[01:18] <donspaulding> the #ubuntu folks told me to come here, even though the most recent version I've found this problem on is Jaunty (haven't tried Karmic yet).  Late in Jaunty's dev cycle I ran into a problem where my T61 would work fine for hours, then it would start behaving weirdly and I'd realize the / fs was mounted read-only.  A subsequent reboot would result in being dumped to a shell after the automatic fsck failed with some UN
[01:20] <donspaulding> I bought a new hard drive, thinking that was the problem, reinstalled Jaunty (before it had been an apt-get upgrade && dist-upgrade) and ran into the same problem.
[01:22] <donspaulding> I installed suse 11.1, and haven't had a problem for 2 months.  Reinstalled the released version of jaunty yesterday, bam, same problem.  It doesn't seem to matter if I use kernel 28-11 or 28-13, both cause problems.  This guy (when not complaining) looks to have experienced the exact same thing as me http://abing.gotdns.com/posts/2009/ubuntu-904-jaunty-jackalope/
[01:23] <donspaulding> anyway, I suppose people in this channel have moved beyond Jaunty, but in case it rang any bells with anyone, I wanted to bring it up.
[01:53]  * TheMuso sighs at drive by comments.
[02:38] <directhex> TheMuso, he pays for support, damnit, it should be instant!
[02:39]  * TheMuso sighs at drive by comments.eh
[02:39] <TheMuso> gah
[02:39] <TheMuso> heh
[02:40] <maco> wonder if he used lvm
[02:41] <maco> i watched dtchen's ext3 choke and get mounted read-only then fsck ate the data
[02:41] <maco> but he said he'd only seen it with lvm, and the error log sounded like something lvm-able
[02:42] <TheMuso> I was wondering whether he was using ext4.
[02:45] <directhex> reiserfs!
[05:52] <lool> cjwatson: Works; thanks
[06:02] <lool> pushed
[06:27] <dholbach> good morning
[06:36] <jussi01> dholbach: morning Daniel :)
[06:37] <dholbach> hey jussi01
[06:52] <ogra> ARGH !!!!
[06:52] <dholbach> ogra: GOOD MORNING!!!!!!!!!!!!! :-)
[06:52] <ogra> so todays update completely reordered all files on my desktop
[06:52]  * ogra curses
[06:53] <ogra> dholbach, hey, morning :)
[06:53] <dholbach> happened to me too
[06:53] <dholbach> don't bother reordering them :)
[06:53] <ogra> well, thats how i keep track of priorities of stuff i work on :)
[06:53] <ogra> little desktop icon clusters :)
[06:54] <dholbach> that explains a lot
[06:54] <dholbach> just kidding ;-)
[06:54] <ogra> heh
[06:54] <dholbach> try gtg - it's REALLY good stuff
[06:57] <ogra> looks like something tomboyish
[06:57] <dholbach> hm?
[06:57] <ogra> gtg
[06:57] <dholbach> I like it because you can categorise and tag stuff, assign due dates, etc.
[06:57] <dholbach> it's good stuff
[06:57] <ogra> looks like tomboy merged with a tasklist
[06:58]  * ogra os only looking at screenshots
[07:00] <ogra> StevenK, i bet you are bored ... and urgently want to push NCommander's uboot-imx through NEW :)
[07:00]  * ogra knows StevenK always waited for doing that ...
[07:00] <pitti> Good morning
[07:01] <ogra> morning pitti
[07:01] <pitti> hey ogra
[07:02] <sbeattie> TheMuso: can I assign you to bugs 395208 and 399084? Or should they go to the kernel team or someone else?
[07:02] <dholbach> hey sbeattie!
[07:02] <sbeattie> hey
[07:03] <TheMuso> sbeattie: Unfortunately I was not the one who decided to try that out, and have been thinking of disabling the powersvae stuff, since I don't know how to fix the hda kernel code to make things work properly.
[07:03] <dholbach> sbeattie: what do you think about a regression test suite session at UDW? :)
[07:03] <TheMuso> So unless dtchen has plans to work on this, I think it will be disabled.
[07:05] <dholbach> sbeattie: maybe the security folks could do it together with you :)
[07:05] <sbeattie> dholbach: where's the schedule?
[07:05] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[07:05] <dholbach> only one slot left
[07:05] <dholbach> if you can't make it at the time, we could try to do some shuffling around
[07:05] <dholbach> it'd be great if more people contributed to it
[07:06] <dholbach> I guess 20:00 UTC is 11:00 your time
[07:07] <sbeattie> dholbach: I agree, it'd be good to get more contributers, was just thinking about presenting it to bugsquad
[07:08] <dholbach> nice, that sounds good
[07:08] <dholbach> good thing with UDW is: you'd still have a bit of time to prepare
[07:08] <dholbach> (although I'd imagine that you get so many questions, that demoing 3-4 examples and talk about it a bit more general would be enough)
[07:08] <sbeattie> dholbach: that time is good, but that friday I'm taking as a vacation day...
[07:09] <dholbach> argh :-(
[07:09] <sbeattie> (long weekend in the US)
[07:10] <dholbach> I could ask agateau, Riddell, bdmurray, jcastro and pedro_ if they'd be willing to swap
[07:10] <dholbach> although pedro, bdmurray and jcastro already swapped once to accomodate others
[07:10] <dholbach> I'm really keen to get the schedule sorted out today, as I'll be on vacatoin afterwards
[07:10] <dholbach> I'll drop everybody an email
[07:11] <dholbach> thanks a lot though sbeattie!
[07:11] <dholbach> sbeattie: I'll pencil you in for now and we'll try to get the swapping done
[07:11] <dholbach> sbeattie: which session title would you like to have?
[07:12] <sbeattie> dholbach: good question.
[07:13] <dholbach> "Effectively testing for regressions" or something?
[07:14] <sbeattie> Sure, that sounds good as a working title.
[07:14] <dholbach> excellent
[07:14] <dholbach> if you want to get in touch with the security folks if they want to hold the session with you, that's cool
[07:14] <dholbach> I'll send out the time swapping email in a sec
[07:14] <dholbach> thanks so much for this, sbeattie!
[07:14] <sbeattie> dholbach: thanks for herding us cats and organizing everything!
[07:15] <dholbach> you wouldn't imagine how much chasing up people it is :)
[07:24] <StevenK> pitti: Right, all of the UNR MIRs are either Invalid or Fix Commited, shall I push the Big Red Shiny Button and start moving stuff to main?
[08:17] <pitti> StevenK: I saw that you backed out fbreader, so go ahead
[08:18] <StevenK> pitti: Should I leave -doc packages in universe, or promote the lot?
[08:18] <pitti> is it just me, or did the latest round of upgrades now cause two mixer applets to appear?
[08:18] <pitti> StevenK: please promote them completely
[08:18] <StevenK> pitti: I'm also going to leave cheese-hildon in universe.
[08:18] <pitti> StevenK: component-mismatches will show what should go back
[08:18] <pitti> but -doc and -dbg have some implicit auto-seeding
[08:19] <RAOF> pitti: Don't think it's only you; #ubuntu+1 thinks so too :)
[08:19] <StevenK> pitti: So cheese-hildon should go to main just to go back, or shall I just ignore it?
[08:19] <highvoltage> cjwatson: good morning, are you around perhaps?
[08:19] <pitti> StevenK: right, you can ignore that; I meant -doc etc.
[08:44] <kirkland> mvo: morning
[08:44] <mvo> hey kirkland - thanks for your uploads
[08:44] <kirkland> mvo: sure :-)
[08:44] <kirkland> mvo: question for you, though ...
[08:45] <kirkland> mvo: so the update-motd package isn't needed any more
[08:45] <kirkland> mvo: there's a blast of failed upgrades, and i don't quite understand why
[08:45] <kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/update-motd/+bug/400462
[08:45] <mvo> are those in launchpad?
[08:46] <kirkland> mvo: ^
[08:46] <kirkland> mvo: ideas?
[08:46] <kirkland> mvo: its strange ...
[08:46] <kirkland> mvo: update-motd gets uninstalled, but then it looks like it wants to configure it
[08:46] <mvo> they look all prety recenent
[08:46] <kirkland> mvo: oh yeah, they're all as of today
[08:47] <liw> kirkland, does update-motd have a postrm?
[08:47] <kirkland> liw: i think it might have a prerm
[08:47] <kirkland> liw: yeah, a prerm
[08:47] <kirkland> liw: and a preinst
[08:48] <mvo> kirkland: let me read the terminal logs
[08:50]  * mvo wonders if its something to do with the latest dpkg changes
[08:55] <mvo> kirkland: you can not reproduce the problem yourself or can?
[08:55] <kirkland> mvo: i did reproduce the problem
[08:55] <kirkland> mvo: but it only happened once
[08:55] <kirkland> mvo: when i dist-upgraded
[08:56] <mvo> kirkland: great, I will try to reproduce it in a VM then here, it might be a problem in libapt (also this part has not changed in a while) or dpkg changed in some way
[08:56] <kirkland> mvo: cool, thanks.
[08:56] <mvo> kirkland: was that on your server or your desktop machine? I noticed that most of the bugreports have a bluez failure, but that may just be coincidence
[08:57] <kirkland> mvo: desktop, and yes, i have bluetooth on that system
[08:57] <StevenK> pitti: Right, everything promoted, and everything set to Fix Released.
[08:57] <pitti> StevenK: yay, thanks
[08:57] <StevenK> pitti: Thank you :-D
[08:58] <mvo> kirkland: thanks. there have been cases in the past were failures there caused this incorrect error message, but I will first try to reprocue
[09:02] <mvo> kirkland: I can reproduce it (yeah!) - now the fun^Wdebugging can start :)
[09:02] <kirkland> mvo:  ;-)
[09:02] <kirkland> mvo: awesome, thanks.
[09:02]  * mvo fills up his tea cup
[09:02] <liw> I see it too
[09:02] <kirkland> mvo: you can have that bug, update it, whatever ;-)
[09:04] <mvo> kirkland: heh :) isn't it pretty late in your TZ now btw ?
[09:04] <kirkland> mvo: yessir, very, very late
[09:04] <kirkland> mvo: it's almost early, even :-)
[09:05] <mvo> heh :)
[09:10] <cjwatson> highvoltage: hi
[09:20] <mvo> kirkland: I updated the bugreport, its debatable I guess if this is a bug in dpkg or apt, but apt can not know if a package is complettely empty on install
[09:20] <kirkland> mvo: hmm, okay
[09:20] <kirkland> mvo: so it's not a bug in update-motd then?
[09:21] <mvo> kirkland: a workaround is to ship with a e.g. README.Debian, that should be ok, the upgrader will suggest to remove update-motd anyway
[09:21] <mvo> kirkland: well, update-motd triggered it and it can work around it
[09:21] <kirkland> mvo: okay, sure, that's easy
[09:23] <liw> that's a fun little bug: gnome has no panels, so no way to shut down or open a terminal; using the power button gives a dialog that doesn't let me shutdown
[09:24] <mvo> liw: and alt-f2 does not work of course?
[09:24] <ogra> welcome to the world of gnome-shell :P
[09:25] <liw> mvo, it might, if I could use it, but kvm isn't letting me
[09:25] <liw> but I could ssh in and shutdown from the command line
[09:25] <liw> ogra, har har
[09:25] <liw> (some days I think I should just stop using desktop systems at all, but text-mode browsing sucks)
[09:25] <ogra> use the framebuffer for the browser then :)
[09:28] <kirkland> mvo: okay, just uploaded an update that does dh_installdocs, which puts a changelog, thanks, copyright file
[09:28] <kirkland> mvo: so the package is no longer empty
[09:29] <kirkland> mvo: that should work around it on my end, right?
[09:33] <mvo> kirkland: yeah, that should fix the problem
[09:33] <mvo> kirkland: I will look into dpkg for a alternative next
[10:35]  * cjwatson takes a deep breath and attempts to update ia32-libs
[10:35] <pitti> cjwatson: with the debian reimplementation or the regular way?
[10:36] <pitti> either way, good luck!
[10:36] <cjwatson> the usual way
[10:36] <cjwatson> don't actually have an amd64 box to hand here :)
[10:36] <mvo> kirkland: I send a bugreport (plus possible patch) to debian, lets see what the dpkg team thinks)
[10:36] <cjwatson> I'm just doing it on ronne
[10:41] <cjwatson> looks like I have to update a few packages to stop depending on NBS things first
[10:42]  * pitti throws a new gdm at the buildds, now more sane \o/
[10:45] <davmor2> cjwatson: if you want I open up ssh on one of my 64bit test boxes :)
[10:46] <sebner> pitti: \o/, I thought only the insane can do great things! xD
[10:46] <davmor2> sebner: Yay there's hope for me yet then :D
[10:47] <sebner> lol
[10:50] <cjwatson> davmor2: I'll stick it up in a PPA once I have something vaguely working, but I think testing it will require an actual graphical session
[10:50] <pitti> tkamppeter: are the hplip udev rules upstream anywhere? (just replying to Tim Waugh's "device permissions" thread)
[10:53] <sebner> pitti: gdm + git. Wow, that's really insane to make it sane :D
[10:54] <pitti> sebner: easeier than keeping to pile up more and more patches
[10:55] <cody-somerville> pitti, launchpad can import git branches ya know
[10:56] <sebner> pitti: now mor tty1 for gdm upgrade right?
[11:05] <pitti> sebner: right, but that was already fixed in a previous version
[11:05] <pitti> cody-somerville: I know, but cloning it directly was much faster than requesting an import and waiting for it to finish
[11:06]  * cody-somerville nods.
[11:06] <cody-somerville> pitti, Are you going to have a chance to review my merge proposal?
[11:06] <sebner> pitti our gdm hero \o/
[11:07] <pitti> cody-somerville: I discussed that with seb128 yesterday, and he asked me to hold back; it seems that gdm really needs more than just g-s-bin
[11:07] <seb128> it needs a settings daemon and a wm to work correctly
[11:07] <cody-somerville> wm, yes
[11:08] <cody-somerville> settings daemon maybe not so much
[11:08] <cody-somerville> we can patch the desktop file to launch x-window-manager instead of metacity
[11:09] <seb128> not sure that's this simple, needs testing
[11:09] <seb128> gnome-session expect the software it runs to register to the session
[11:09] <cody-somerville> I agree
[11:10] <cody-somerville> I've tested it and xfwm4 does indeed timeout
[11:10] <cody-somerville> however, I want to try and bring down the Xubuntu cd size back to normal so people can continue to test
[11:10] <cody-somerville> with the way things are now, half of gnome gets pulled into Xubuntu
[11:11] <seb128> use xdm?
[11:11] <cody-somerville> ...
[11:11] <cody-somerville> Thats not a very sustainable solution.
[11:11] <seb128> why?
[11:11] <seb128> it should do the start a session job just fine no?
[11:11] <mr_pouit> but it's ugly?
[11:12] <cody-somerville> and I heard from bryce that it doesn't setup the proper security context
[11:12] <seb128> I've no good reply, GNOME upstream don't design their software to make sure they work without GNOME
[11:12] <seb128> so the new gdm is harder to make work in a non GNOME context
[11:12] <simon-o> cody-somerville: what about slim? that's fast and looks nice
[11:12] <seb128> and I'm not sure they will take patches for that
[11:12] <seb128> so maybe it's time to look at an another login manager for xubuntu
[11:13] <cody-somerville> seb128, It may come to that but for now we're going to attempt to integrate the new gdm for Xubuntu
[11:13] <seb128> ok, good
[11:13] <seb128> you will have to solve the need for a settings daemon and the registration issue then
[11:14] <mr_pouit> simon-o: "SLiM is looking for a new maintainer!" on its homepage
[11:14] <simon-o> mr_pouit: Just saw that too, that's sad. They did a great job
[11:15] <cody-somerville> seb128, For now, can we patch gdm to depend on gnome-session-bin and to launch x-window-manager instead of metacity?
[11:16] <seb128> that will create those timeout registration error for some users if they don't have x-window-manager set to a working alternative
[11:16] <seb128> and we still need gnome-settings-daemon to be pulled in
[11:16] <seb128> without it there is no accessibility, no theming, etc
[11:16] <cody-somerville> seb128, Sure but gdm isn't the only thing in Ubuntu that depends on g-s-d
[11:16] <cody-somerville> seb128, and g-s-d is *not* a hard dependency
[11:17] <seb128> well it's a recommends if you want
[11:17] <seb128> ie it will be pulled in with gdm
[11:19] <cody-somerville> seb128, Can we make it a suggest for now so that the daily builds can be useful?
[11:20] <seb128> can't you try to come with a working solution?
[11:20] <seb128> if we workaround it nobody will care and that will stay this way
[11:23] <cody-somerville> seb128, I was thinking I would investigate patching gdm to run x-session-manager instead of gnome-session directly
[11:24] <cjwatson> maybe the settings daemon should be an alternative too ...
[11:24] <cjwatson> not sure how to make that a generic concept
[11:24]  * cody-somerville nods.
[11:26] <hile> btw what has changed that the settings daemon requires so much of gnome to run? or has it always required, but gdm did not require it?
[11:26] <cody-somerville> hile, gdm got rewritten pretty much
[11:29] <seb128> hile, gdm used to be a gtk software now it's basically a gnome session
[11:29] <seb128> they use gnome-session + a custom autostart set
[11:30] <hile> ok
[11:30] <hile> makes sense, from gnome pov
[11:32] <pitti> seb128: well, we'll still have g-s-d in the gnome CDs anyway, so lowering the dependency in gdm itself shouldn't hurt us at all?
[11:32] <pitti> seb128: and gdm without accessiblity is still better for xubuntu than xdm (which doesn't have all those fancy things either)
[11:32] <seb128> pitti, it's technically wrong though, it means somebody with a minimal install doing apt-get install gdm will get a non working gdm
[11:34] <seb128> pitti, I'm happy to use alternative depends
[11:34] <pitti> cody-somerville: would there be an appropriate g-s-d alternative for xubuntu, so that it could Depends: g-s-d | xfce-something ?
[11:34] <seb128> ie gnome-session | xfce-session
[11:34] <pitti> seb128: right, just thinking that
[11:35] <cody-somerville> xfconf
[11:36] <seb128> I'm not sure it will work without gdm changes but that's rather a xubuntu change
[11:36] <seb128> let's add the alternative depends now and let them sort how they make that work for them then
[11:36] <pitti> I guess xfconf will work fine if you also change metacity to xfwm?
[11:36] <seb128> they still need a session manager though
[11:37] <seb128> or something running the autostarts
[11:37] <pitti> gome-session-bin?
[11:37] <cody-somerville> for now, lets depend on gnome-session-bin
[11:37] <seb128> no
[11:37] <seb128> gnome-session | xfce-something rather
[11:37] <cody-somerville> no, thats still wrong
[11:38] <seb128> I'm not going to depends on gnome-session-bin that's not enough requirement to get gdm working correctly
[11:38] <pitti> gnome-session-bin, gnome-session | xfce-session, metacity | xfwm, gnome-settings-daemon | xfconf
[11:38] <pitti> ?
[11:38] <seb128> we need gnome-settings-daemon too for example
[11:38] <seb128> and gpm
[11:38] <seb128> and some accessibility tools
[11:38] <cody-somerville> those aren't dependencies
[11:38] <seb128> they are
[11:38] <cody-somerville> no they are not
[11:38] <pitti> perhaps at this point it would make more sense to build another gdm-xfce with all the dependencies swapped?
[11:38] <seb128> when you apt-install gdm on a minimal install you should get the full user experience
[11:39] <seb128> Recommends if you want but gdm should pull those
[11:39] <cody-somerville> seb128, and that'll happen but things like gpm would be a recommend and not a depend
[11:39] <seb128> which doesn't fix your CD build issue
[11:39] <pitti> seb128: my depends line from above would provide that
[11:39] <cody-somerville> seb128, we already include gpm
[11:39] <seb128> pitti, if you do that make sure it pulls also accessibility tools required, gpm, etc
[11:40] <pitti> sure, it wasn't the complete line, just illustrating
[11:40] <seb128> would be easier to have "gnome-session | xsomething"
[11:40] <cody-somerville> we might decide to use gnome-session-bin
[11:40] <pitti> ^ that still needs an additional gnome-session-bin
[11:40] <seb128> right
[11:40] <pitti> (which is a no-op for ubuntu)
[11:40] <seb128> I'm not arguing that ;-)
[11:40] <pitti> okay
[11:40] <seb128> just don't drop the gnome-session depends if you don't add all the required components
[11:41] <seb128> ie make sure that you do a minimal install, apt-get install gdm and get it working correctly
[11:41] <seb128> not complaining about some tools missing or themes not working or something
[11:41] <ogra> did we drop the old gdm completely ?
[11:42] <pitti> ok, sounds like a plan
[11:42] <seb128> yes
[11:42] <pitti> cody-somerville: does that work for you, too?
[11:43] <cody-somerville> gdm should not directly depend on gnome-session but instead gnome-session-bin but *should* as seb128 ensure that the right stuff gets pulled in like some of the stuff that automagically got pulled in when depending on gnome-session
[11:44] <cody-somerville> *as seb128 said
[11:44] <pitti> cody-somerville: i. e. the dependency scheme from above (gnome-session-bin, gnome-session | xfce-session, metacity | xfwm, gnome-settings-daemon | xfconf)
[11:44] <pitti> cody-somerville: *nod*
[11:44] <pitti> cody-somerville: then you just need to make sure that those alternative dependencies occur before gdm in the xubuntu seeds
[11:45] <cjwatson> I don't think you even need that - germinate should add all directly specified packages before trying to resolve any of their dependencies
[11:46] <pitti> ah, nice
[11:46] <cody-somerville> pitti, so I would see the deps being like this for now: gnome-session-bin, x-window-manager, gnome-settings-daemon | xfconf
[11:46] <pitti> cody-somerville: x-window-manager isn't a real package
[11:46] <cody-somerville> pitti, right-o
[11:46] <pitti> metacity | x-window-manager would work
[11:46]  * cody-somerville nods.
[11:47] <pitti> i. e. you need to specify a preferred real package
[11:58] <pitti> kirkland: why did you reopen bug 400462 ?
[12:01] <cjwatson> gah, ia32-libs/fetch-and-build only works when all the binary packages it wants are in sync with its sources :-(
[12:02]  * cjwatson waits another hour ...
[12:02] <pitti> cjwatson: IIRC there was a magic env var to override the check
[12:02] <pitti> I think I added that ages ago when I was annoyed by exactly that
[12:06] <cjwatson> pitti: I don't see one, but it doesn't matter, I can do other things
[12:07] <pitti> cjwatson: SOURCE_VER_MISMATCH=1
[12:07] <cjwatson> oh so there is
[12:07] <cjwatson> thanks
[12:08] <pitti> I haven't played around with ia32-libs-tools yet, but it seems much easier to maintain
[12:08] <pitti> (and avoids the OMG 400 MB packages)
[12:08] <cjwatson> yeah, but I'm worried about the fact that it requires an extra manual apt-get dist-upgrade after the first upgrade
[12:09] <cjwatson> if we're actually getting multiarch (which seems not entirely implausible now) then I'd sort of rather skip straight to that
[12:09] <pitti> *nod*
[12:10] <pitti> anything that gets us rid of this excruciating ia32-libs pain is a major step forward
[12:10] <tkamppeter> pitti, I have still to inform the HP guys about their new UDEV rules.
[12:20] <pitti> ogra, lool: do we have daily armel CD builds for UNR? (Stefan Vogelsang was interested)
[12:20] <ogra> no
[12:20] <ogra> we only build live images but are lacking kernels
[12:20] <ogra> (s/live/ubuntu-desktop/)
[12:22] <pitti> ogra: oh, so http://cdimage.ubuntu.com/ports/daily-live/current/ armel won't work either?
[12:22] <ogra> right
[12:22] <pitti> ok, thanks
[12:22] <ogra> there is no content in the kernel package thats used
[12:22] <ogra> so it wouldnt boot
[12:23] <ogra> pitti, we're supposed to have kernels for the two arches we will build for by A4
[12:28] <lool> pitti: We don't due to lack of OpenGL drivers or 2D version of UNR
[12:29] <lool> pitti: I just deferred the specs for this cycle, as it's a bit late to add these now
[12:32] <ogra> right, that too :)
[13:48] <Keybuk> superm1: I really hate the Mini 10v's touchpad, like, seriously wtf
[13:48] <Keybuk> ;)
[13:53] <ion> I couldn’t live without a wacom-enabled tablet PC anymore. :-P
[14:15] <tseliot> Keybuk: what's the problem? (I might already be working on it)
[14:17] <tseliot> about the touchpad, I mean
[14:44] <Keybuk> tseliot: that the mouse buttons are embedded in it
[14:44] <Keybuk> so it's impossible to click without violently moving the mouse pointer
[14:44] <tseliot> Keybuk: my patch was accepted today: http://bugs.freedesktop.org/show_bug.cgi?id=21613
[14:45] <Keybuk> tseliot: I'd rather have an option to turn the buttons off and use tap-to-click
[14:45] <tseliot> Keybuk: you have an option to do that
[14:45] <Keybuk> where?
[14:46] <tseliot> Keybuk: you can set it with xinput
[14:47] <Keybuk> how?
[14:51] <tseliot> Keybuk: xinput set-int-prop $YOU_DEVICE_NAME "Synaptics Click Action" 8 0 0 0
[14:51] <tseliot> this should do it
[14:51] <Keybuk> why the 8?
[14:52] <Keybuk> that appears to have changed the property, but the buttons still work
[14:52] <tseliot> 8 bit
[14:52] <Keybuk> in fact
[14:52] <Keybuk> that has disabled tap-to-click
[14:52] <Keybuk> not the buttons
[14:52] <tseliot> weird, let me check
[14:55] <tseliot> Synaptics Tap Action should disable taps while Synaptics Click Action is supposed to disable clicks
[14:55]  * tseliot has a look at the code
[14:58] <tseliot> Keybuk: I don't see anything wrong in the code. Can you file a bug report about it and assign it to me, please?
[15:00] <Keybuk> sure
[15:00] <Keybuk> which package?
[15:03] <tseliot> xorg-driver-synaptics
[15:04] <tseliot> xserver-xorg-input-synaptics
[15:04] <tseliot> Keybuk: ^^
[15:05] <Keybuk> tseliot: thanks, bug #400697
[15:06] <ScottK> tseliot: How about the other patch?
[15:07] <tseliot> Keybuk: thanks
[15:07] <Keybuk> seriously though, this Touchpad is the kind of idea that must have gone straight from concept to production without passing through a brain in between
[15:07] <tseliot> ScottK: the other patch is still work in progress. I have to make sure that it doesn't break other touchpads. I'm discussing this with upstream
[15:08] <tseliot> heh
[15:08] <ion> What – a touchpad that sucks even *more*? Is that possible?
[15:08] <ScottK> Keybuk: tseliot's patches seem to tame it a bit.
[15:09]  * ScottK is no longer considering throwing his through a window.
[15:10] <tseliot> hehe
[15:15] <Keybuk> tseliot: is that something that might not work on Jaunty but might work on Karmic?
[15:17] <tseliot> Keybuk: I'm using the driver from upstream, therefore I don't think so
[15:18] <tseliot> but anyway let me try on Karmic (just in case it's a kernel issue)
[15:18] <Keybuk> it was jaunty-release that I tried that xinput on
[15:20] <tseliot> ok, I tried it on Jaunty + upstream's x driver and it didn't work
[15:21] <tseliot> it doesn't work on Karmic either
[15:23] <tseliot> wait a second that just customises left clicks
[15:26] <tseliot> Keybuk: my bad. It can be done from Xinput
[15:26] <tseliot> s/can/can't/
[15:27] <cudev> Can someone please expand upon what "if-up.d/mountnfs [device__]: lock /var/run/network/mountnfs exist, not mounting" means?
[15:27]  * tseliot should RTFM more carefully...
[15:29] <tseliot> Keybuk: sorry but you'll have to use the 1st solution that I suggested :-/
[15:30] <Keybuk> tseliot: what was that?
[15:30] <superm1> pitti, cody-somerville so in this new gdm upload, glancing thru the changelog still no solution for having it depend on gnome-session-bin yet right?
[15:30] <cody-somerville> superm1, I thought we had a solution
[15:31] <tseliot> Keybuk: use the driver from upstream and type: xinput set-int-prop $YOUR_DEVICE_ID "Synaptics Area" 32 0 0 0 4000
[15:32] <pitti> superm1: that was discussed this morning, and I think we have a working agreement now
[15:33] <Keybuk> tseliot: but I don't want to change the touchpad area
[15:33] <Keybuk> I want to turn off the buttons
[15:33] <superm1> Keybuk, the buttons dont go crazy when you change that area
[15:33] <superm1> they act more like normal touchpad buttons
[15:33]  * ogra hands Keybuk a soldering iron
[15:33] <superm1> pitti, yeah i saw some of the discussion in scrollback, it just hasn't made it into "this upload" (i'm looking for when xubuntu and mythbuntu disks can start being tested again)
[15:34] <Keybuk> superm1: but that will introduce an invisible magic line inside which the touchpad works and outside which it doesn't
[15:35]  * superm1 hands Keybuk a permanent marker :P
[15:35] <Keybuk> superm1: I have a hammer
[15:35] <ogra> heh, you will sonn have a full toolbox if that goes on :)
[15:35] <ogra> *soon
[15:36] <tseliot> Keybuk: maybe try with xmodmap?
[15:37] <tseliot> and change the pointer map?
[15:38] <Keybuk> tseliot: second Q, which package do I install on karmic to get the wireless to work?
[15:39] <tseliot> Keybuk: bcmwl
[15:41] <pkt> why is packagekit-udev-helper not in ubuntu? (or is it in and I missed it?)
[15:43] <Keybuk> tseliot: err, that area thing doesn't work either
[15:43] <tseliot> Keybuk: doesn't it ignore movements and taps in the bottom area?
[15:43] <Keybuk> nope
[15:44] <tseliot> Keybuk: are you using the driver from upstream?
[15:45] <tseliot> today's snapshot
[15:46] <tseliot> Keybuk: I've found the solution
[15:47] <tseliot> type: xinput set-button-map $YOUR_TOUCHPAD 12 12 12 4 5 6 7 8 9 10 11 12
[15:48] <Keybuk> ... :-)
[15:48] <tseliot> the trick is to set the 1st three buttons to a higher code
[15:48] <Keybuk> set the first three buttons to button 12? :)
[15:48] <tseliot> yes, or to whatever you like
[15:48] <tseliot> it works well here
[15:49] <Keybuk> just 12 12 12 works
[15:50] <Keybuk> ah
[15:50] <tseliot> that too ;)
[15:50] <Keybuk> no
[15:50] <tseliot> no?
[15:50] <Keybuk> that disables tap-to-click as well ;-)
[15:50] <Keybuk> tap-to-click is now sending button 12 too
[15:50] <tseliot> I guess it's the same event
[15:51] <tseliot> you can test it with xev
[15:53] <tseliot> back to my 1st solution then
[15:53] <tseliot> again
[15:53] <Keybuk> which didn't work either ;)
[15:54] <ogra> some thick duct tape ?
[15:55] <tseliot> Keybuk: are you using upstream's code
[15:55] <Keybuk> tseliot: I'm using Ubuntu
[15:55] <tseliot> Keybuk: that's a no then
[15:55] <tseliot> my patch was accepted today
[15:55] <Keybuk> it's in today's Ubuntu?
[15:56] <tseliot> no, here: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=7179a0eb11a842d9d5a420f5702a411b0dc217a2
[15:56] <tseliot> in freedesktop, that is
[15:57] <Keybuk> oh, well, if you haven't _packaged_ it ;-0
[15:57] <tseliot> I can put it in my PPA
[15:58] <Keybuk> this machine's used for boot performance testing - I don't want to install anything on it that's not in the official repo to avoid skewing results
[15:58] <tseliot> It's pretty much like the version in Karmic + a bunch of patches
[15:58] <Keybuk> exactly <g>
[15:59] <tseliot> ok, I'll bug someone to upload it to Karmic next week
[15:59] <tseliot> ;)
[15:59] <tseliot> better?
[15:59] <Keybuk> much! :D
[15:59] <tseliot> ok
[16:04] <mvo> Riddell: could you please add me as admin to the software-properties project page? I would like to update some stuff and it seems like you own it currently :)
[16:05] <kirkland> pitti: because it came back up
[16:06] <Riddell> I do?  amazing what one is sometimes
[16:06] <kirkland> pitti: talked to mvo last night, and it's a dpkg/apt issue
[16:06] <pitti> kirkland: hey; sorry, context?
[16:06] <pitti> kirkland: ah, right, the update-motd bug
 kirkland: why did you reopen bug 400462 ?
[16:06] <kirkland> pitti: a problem with empty packages
[16:07] <kirkland> pitti: so i "fixed it" by putting a file (copyright) back into the package
[16:07] <pitti> heh
[16:07] <pitti> that's policy anyway
[16:07] <kirkland> pitti: oh, i see what you mean
[16:08] <pitti> kirkland: so it needs to be fixed harder, with some preinst magic?
[16:08] <kirkland> pitti: my marking it confirmed, and my upload were racing one another :-)
[16:08] <pitti> ah, ok
[16:08] <pitti> so it shold really be closed
[16:09] <kirkland> pitti: yessir
[16:09] <Riddell> mvo: only one person or team can be Maintainer of a project it seems, I can set it to you, or is there a team which would be more suitable?
[16:10] <mvo> Riddell: I don't know of a team, but we can create one, I just want to link trunk to the lp:~ubuntu-core-dev/software-properties/main branch
[16:10] <cjwatson> mterry: what's happening with the librelp MIR? it seems to be on your plate for a correction?
[16:11] <cjwatson> (but not assigned to you - seems a bit ambiguous)
[16:11] <mvo> Riddell: if you could do that, then I'm happy :)
[16:12] <Riddell> mvo: done, I think
[16:13] <mvo> Riddell: cool, thanks
[16:32] <kirkland> pitti: thanks for going through the kvm sru feedback ;-)
[16:32] <kirkland> pitti: that was a lengthy, complex set :-)
[16:32] <pitti> kirkland: you're welcome
[16:37] <cjwatson> evand: foundations-karmic-usb-creator-for-windows is still "not started" in LP - that isn't accurate, is it?
[16:37] <evand> ah, fixing
[16:38] <evand> thanks
[16:40] <Keybuk> cjwatson: err, we're installing ubuntuone by default now?
[16:41] <cjwatson> Keybuk: per https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[16:42]  * Keybuk explodes with fury
[16:42] <Keybuk> clearly I should just give up
[16:42] <cjwatson> desktop team matter, this is the first I knew about it although of course I knew it was planned
[16:42] <Keybuk> cjwatson: can I mark boot performance as an abandoned spec then?
[16:42] <Keybuk> there's no point if we're adding services that take 25s to start on their own!
[16:42] <cjwatson> pitti: ^-
[16:43] <cjwatson> we should regard this as a critical problem with the ubuntuone packages
[16:43] <cjwatson> (and, if it can't be resolved, act appropriately for new features with critical problems)
[16:44] <pitti> Keybuk: 25 seconds??
[16:44] <Keybuk> pitti: yup
[16:45] <Keybuk> 15s seems about average though
[16:45] <Keybuk> that 25s may have been competing with apt-check (another thing I'm going to get annoyed about soon)
[16:45] <Keybuk> even 15s is 150% of the entire boot time
[16:45] <cjwatson> perhaps we should make anacron not attempt to catch up with cron jobs until well after boot
[16:45] <pitti> I didn't notice any difference, but if it's taking so much time, we should start it a minute later or so
[16:45] <cjwatson> you typically don't want them to run immediately you start up anyway
[16:46] <Keybuk> cjwatson: it already does back up for a while
[16:46] <Keybuk> pitti: I don't consider that a fix
[16:46] <pitti> well, network sync can only be so fast
[16:46] <pitti> and it's not even enabled by default; but if you do, you certainly want it to work?
[16:47] <Keybuk> if you enable it, and turn on sync, and have files to sync, sure, it can take as long as it likes
[16:47] <Keybuk> but on a default install
[16:47] <Keybuk> on the first boot
[16:47] <pitti> Keybuk: anyway, would you mind filing a bug about it, so that I can channel it to OLS, etc.?
[16:47] <Keybuk> when I have not enabled it
[16:47] <Keybuk> and I have no account
[16:47] <pitti> (sorry, I'm in meeting)
[16:47] <Keybuk> and I have no files to sync
[16:47] <Keybuk> it should NOT TAKE FIFTEEN SECONDS!
[16:47] <pitti> Keybuk: agreed, that's a bug
[16:47] <Keybuk> pitti: I've filed bug #400746 and I have subscribed the release team
[16:48] <pitti> Keybuk: splendid, thanks
[16:48] <cjwatson> marked rc
[16:48] <cjwatson> (i.e. release-targeted)
[16:49] <mterry> cjwatson, Yar, I was in the middle of updating the bug with the upstream author's comments.  he basically said not to worry, but I'm verying what he said.  I'll update the bug today
[16:49] <mterry> cjwatson, (^^ above was re: librelp MIR)
[16:49] <cjwatson> kees: ^-
[16:50] <pitti> Keybuk: thanks for pointing out
[16:58] <james_w> al-maisan: thanks for the patch
[16:58] <james_w> al-maisan: I think it might not quite be correct
[16:58] <al-maisan> james_w: please explain.
[16:58] <james_w> if I remember correctly the _parse_error just warns if strict == False
[16:58] <james_w> so you would still get an error as it did the [-1] afterwards
[16:59] <james_w> (just going on memory)
[16:59] <james_w> some form of "return" or something would fix that
[17:00] <al-maisan> james_w: good point .. let me address that.
[17:00] <james_w> thanks
[17:01] <james_w> then I'll try and fight with git to commit it upstream for you
[17:02] <james_w> cjwatson: I've just implemented collision handling in the importers
[17:02] <james_w> no guarantees that it will work, but it will at least try and do something now rather than freaking out
[17:03] <james_w> you can't create merge proposals with the API yet, so I'm filing a bug instead and I'll create the merge proposals by hand
[17:05] <al-maisan> james_w: I think all it takes is an additional return statement, see http://pastebin.com/m368d17ba
[17:07] <james_w> sounds about right
[17:07] <james_w> thanks al-maisan
[17:07] <al-maisan> james_w: thank *you*
[17:07] <cjwatson> james_w: nice, thanks for the note
[17:08] <james_w> I'm glad I got it done by the time LP allowed everyone to right and it became "OMG!!!"
[17:08] <\sh> hmm..I have a very strange ssh client problem...I have .ssh/config setup for hosts with pubkey auth...but it looks like that ssh client sends all keys found in .ssh/id_rsa.pub to the host..and the host is telling me "too many auth errors"...which seems very wrong to me...but I could be mistaken
[17:08] <\sh> s/to the host/to the host which is not configured in .ssh\/config/
[17:09] <al-maisan> james_w: would you be willing to sponsor the change? Otherwise I'll start harassing mvo ;)
[17:09] <maco> \sh, by default it should try id_rsa and id_dsa but ignore id_rsa.2 and such
[17:09] <james_w> al-maisan: I'm committing it upstream, I'll also ask them to upload it to Debian
[17:09] <al-maisan> james_w: thanks!
[17:10] <maco> perhaps that host doesnt like even getting the 2 of them?
[17:10] <\sh> maco: tbh, I don't have a standard id_rsa / id_dsa all keys are named differently..
[17:10] <maco> oh
[17:10] <cjwatson> you aren't supposed to put multiple keys in id_rsa.pub
[17:10] <cjwatson> one key and one key only
[17:10] <\sh> cjwatson: it isn't :)
[17:11] <cjwatson> "all keys found in .ssh/id_rsa.pub"
[17:11] <cjwatson> what does that mean if you don't have multiple keys there?
[17:11] <\sh> cjwatson: sorry..typo
[17:11] <\sh> http://paste.ubuntu.com/220653/ <- my .ssh dir
[17:11] <cjwatson> anyway, use IdentitiesOnly if ssh is sending more keys than you want
[17:11] <cjwatson> ssh_config(5)
[17:12] <\sh> cjwatson: and what if ssh-agent is not running?
[17:13] <cjwatson> \sh: don't believe it, ssh doesn't magically send extra keys unless some agent has then
[17:13] <kees> cjwatson: that was for Keybuk, not me, yes?
[17:13] <cjwatson> them
[17:13] <cjwatson> \sh: remember that things like gnome-keyring implement the agent protocol ...
[17:14] <cjwatson> kees: no - you're the assignee of the librelp MIR bug right now, and the last person to ask a question on it
[17:16] <\sh> cjwatson: so..if I say to /etc/X11/Xsession.options: don't start ssh-agent, and i remove the lines in /etc/gdm/Xession which are starting the ssh-agent, too (which I don't understand) then I have still something started like gnome-keyring which does the very same thing? sounds very insane to me
[17:16] <kees> cjwatson: oh! sorry, missed the context on that.
[17:16] <cjwatson> \sh: don't look at me, I'm not a fan of gnome-keyring pretending to be ssh-agent either
[17:17] <kees> I just wish gnome-keyring had a timeout for it's ssh-agent emulation.
[17:17] <\sh> cjwatson: I don't, really...but I really wonder why we have at least to "ssh-agent" starting mechanisms (one of X11 Xsession, which is configurable) and a static "start ssh-agent when you find it on the system" in /etc/gdm/Xsession script (without somehow any configuration) (and forget gnome-keyring or seahorse)
[17:18] <TwoToneSpirit_Bi> #dd-wrt
[17:18] <ogra> \sh, you cant have enough security ;)
[17:19] <\sh> ogra: ssh-agent is not for security, it's for lazy people to not enter their passphrase
[17:20] <ogra> i know :P
[17:20] <cody-somerville> it also pops up a dialogue
[17:20] <cody-somerville> so you enter it into the dialogue instead of la terminal
[17:20] <\sh> (actually when they do use passphrases)
[17:20] <ogra> but it has ssh in the name, so it must secure something :)
[17:20] <pitti> slangasek: FYI, I forwarded the cdbs python change to debian bug 537373; it can't be applied until doko uploads the experimental python2.{4,5} to unstable, though
[17:20] <cody-somerville> lol
[17:20] <cjwatson> cody-somerville: ssh can do that itself too
[17:21] <cjwatson> depending on configuration
[17:21] <cody-somerville> Interesting. I didn't know that.
[17:21] <\sh> cody-somerville: you enter it once, and without a sane timeout it never shows any popup again...so start your session and leave it open for a while
[17:21] <cjwatson> cody-somerville: in fact, ssh-agent itself never asks for a passphrase - that's ssh-add
[17:22]  * cody-somerville cuddles his seahorse.
[17:22] <\sh> cody-somerville: seahorse is broken with gnupg smartcards ... so I can't use it...
[17:26] <ion> sh: I have a script that starts keychain in the session, and i source it from /etc/profile, /etc/zsh-beta/zshrc and /etc/X11/Xsession.d/89keychain. Gnome’s own ssh agent seems to break it, though. I haven’t got around to investigate/fix that yet.
[17:27] <ion> sh: apt-cache show keychain
[17:31] <\sh> ion: the fun part is, it started this morning when I updated jaunty with the latest updates...
[17:32] <slangasek> pitti: ok, thanks :)
[17:35] <\sh> anyways..this identitiesonly yes works ... thx cjwatson
[17:51] <fbond> Hi.  How can I find out what time a version of a package hit the archives?
[17:51] <ogra> launchpad
[17:53] <fbond> ogra: launchpad has many pages ... can you be more specific?
[17:53] <ogra> could you ?
[17:53] <ogra> :)
[17:53] <ogra> which package ?
[17:53] <fbond> grub
[17:53] <fbond> I can see the changelog there, or course.
[17:54] <fbond> But that date is not the date that the packgae hit the archive necessarily, right?
[17:54] <fbond> Oh, publishinghistory, eh?
[17:54] <ogra> https://launchpad.net/ubuntu/karmic/+source/grub/0.97-29ubuntu56
[17:54] <ogra>     * Published on 2009-06-30
[17:54] <fbond> ogra: thanks
[17:55] <cjwatson> that tells you when the source was published
[17:55] <ogra> right
[17:55] <cjwatson> to find out for a binary, go to the build page for the binary in question, and add an hour or so to the completion time there
[17:56] <fbond> I'm really trying to figure out if a grub update went out for Jaunty between yesterday and today.  I'm seeing some strange failures with update-grub in an automated build I've been working on.
[17:58] <jjohansen> has anyone else hit a bug where firefox throws up several hundred help tabs and you get dozens gnome terminal help windows?
[17:58] <ogra> sounds like a kbd or xinput issue
[17:58] <ion> Yeah, every time i fall asleep on the F1 key
[17:58] <fbond> jjohansen: Using a KVM?  USB keyboard?
[17:59] <jjohansen> fbond: no
[17:59] <jjohansen> no usb keyboard and KVM is not currently running
[17:59] <fbond> Err, KVM switch.
[17:59] <infinity> That problem is usually my cat.
[18:00] <jjohansen> or in my case kids, but I have seen happen spontaneously a few times now
[18:01] <infinity> cjwatson: Binary publishing history works just by swapping +source for <arch>, as in something like https://edge.launchpad.net/ubuntu/karmic/i386/libc6
[18:02] <infinity> cjwatson: (ie: no need to "count an hour past of build time")
[18:03] <\sh> uhohah...karmic gnome looks really great...
[18:05] <sebner> \sh: karmic \o/
[18:06] <dholbach> have a good time without me - see you soon again! have a great WE my friends!
[18:06] <sebner> dholbach: hf! I wish you nice holidays! :)
[18:06] <cjwatson> infinity: oh, nice
[18:07] <dholbach> thanks sebner
[18:07] <cjwatson> infinity: though you still have to add a bit as that's the start of the publisher run, but same goes for source pubs
[18:08] <infinity> cjwatson: *nod*
[18:09] <ogra> tsk ... 1h after publisher run ... /me learned to could 600 min after upload ... at least for the armel stuff :P
[18:09] <ogra> *count
[18:09] <infinity> cjwatson: I've always thought an actual file-on-disk-on-primary-mirrors (so, not on cocoplum, but on $random_archive_ubuntu_com_machine) prober that then wrote the value back to the DB would be kinda cool, but pretty heavyweight.
[18:11] <infinity> cjwatson: So, publishing history would show "published at 04:32; on primary mirrors at 04:56" or something.
[18:12] <cjwatson> yeah
[18:12] <cjwatson> then people'd want it to probe au.archive and stuff ;-)
[18:13] <ogra> infinity, could you turn that 10h timeout back to normal since it didnt gain us something a package that has the issue just effectively blocks a buildd for half a day
[18:14] <infinity> cjwatson: Well, there's no sane way to implement even my pipe dream, so it ain't happening. :)
[18:16] <infinity> ogra: Yeah, doing so no.
[18:16] <ogra> gracias
[18:18] <infinity> ogra: Done.
[18:18] <ogra> thanks a lot
[18:18] <ogra> i hope we'll find out what it is soon
[18:19] <infinity> ogra: I'm going to try to look into it a bit first thing next week.
[18:19] <infinity> ogra: Do you have a package that's a reasonably short build that exhibits the issue?
[18:19] <ogra> cool, i'll make sure i'll be around
[18:19] <ogra> well, mesa is the quickest i guess
[18:20] <ogra> though thats still a 3-4h build
[18:20] <ogra> and it only seems to show up at dpkg-deb very late in the build
[18:20] <ogra> at least thats what NCommander said
[18:21] <infinity> Yeah, I know vaguely when and where it happens.  Just hoping I don't have to wait all day to see it and debug it. :)
[18:21] <ogra> beyond mesa most KDE packages show the issue
[18:21] <NCommander> hey infinity
[18:21] <ogra> i dont think there is one thats actually a fast build among the problematic ones
[18:22] <NCommander> infinity, the problem usually crops up in packages that are doing lzma compression on relatively huge datafiles
[18:22] <ogra> NCommander, what are you doing here, you took the day off :P
[18:22] <NCommander> ogra, I felt the need to be summoned
[18:23] <ogra> yeah, i'll say "michael" next time if i mention you ... :P
[18:23]  * NCommander is still finding everything he needs to pack :-/
[18:24] <ogra> NCommander, did you see my toying around results today ? https://wiki.ubuntu.com/ARM/BuildEABIChroot
[18:25] <NCommander> ogra, I found that to be extremly unstable
[18:25] <NCommander> ogra, with unimplemented syscalls everywhere when I tried it
[18:25] <NCommander> if its stable for you then, maybe upstream has improved it greatly
[18:26] <ogra> did you try the 20 or so patches ?
[18:26] <ogra> well, i added that patchset and afaik its what OBS uses as well
[18:26] <NCommander> ogra, that's very sexy :-)
[18:26] <ogra> it built mesa without issues and rolls chroots just fine
[18:27] <NCommander> ogra, I think you found a solution for the buildd issue
[18:27] <ogra> not for production use, there are surely still missing syscalls
[18:27] <ogra> but for testbuilding at home its perfectly right
[18:28] <NCommander> ogra, nifty. Nice work. You could try rebuilding the base system, thats usually a pretty good environment stress test.
[18:28] <ogra> i might do tht on the weekend ... though its really not the porpose to act as buildd :)
[18:29] <ogra> what do you think causes the timeout issue ? i'm curious
[18:29] <NCommander> ogra, no idea. We ruled out hardware and the software individually
[18:30] <ogra> sorry, i'm to tired :P
[18:30] <ogra> i read "I think *I* found a solution for the buildd issue"
[18:30]  * NCommander starts a caffiene drip into your ARM
[18:31] <NCommander> er
[18:31] <NCommander> wow
[18:31] <NCommander> shoot me
[18:31] <ogra> heh
[18:31] <ogra> nah, i should really stop for the day ... to short night, long day and i'm still chatting
[18:32]  * ogra decides to do so ...
[18:32] <NCommander> Indeed
[18:32]  * ogra calls it a day
[20:38] <cjwatson> would anyone with a karmic amd64 system like to test https://launchpad.net/~cjwatson/+archive/ia32-libs-testing, please?
[20:38] <cjwatson> see the changelogs for the list of bugs it's meant to fix
[20:41] <jpds> cjwatson: http://paste.ubuntu.com/220760/
[20:41] <slangasek> cjwatson: sure, pulling
[20:41] <slangasek> oh, or that
[20:41]  * jpds ponders dist-upgrading.
[20:42] <slangasek> that wouldn't help, though?
[20:42] <donspaulding> ok, so I updated my jaunty box to karmic (by editing sources.list && update && upgrade && dist-upgrade), rebooted and got a grub "Error 2" message on boot.  I'm back in with a jaunty livecd, how can I mount the karmic partition in the live environment and reinstall grub?
[20:42] <slangasek> karmic doesn't have libc6-i386 (>= 2.9-18), that's pending the eglibc merge
[20:42] <jpds> slangasek: Oh right.
[20:42] <donspaulding> or rather, how do I reinstall grub for the karmic installation from the jaunty livecd?
[20:43] <slangasek> cjwatson: darn, would've been happy to test since that would fix the flash+pulse problem, but I guess we're blocked on eglibc
[20:43] <jpds> donspaulding: Try #ubuntu+1 for support.
[20:43] <donspaulding> jpds: ouch, sorry didn't read the topic apparently.
[20:59] <A|i> who's the packman for mysql-server?
[21:00] <cjwatson> jpds: drat
[21:00] <cjwatson> slangasek: eglibc is in NEW, if you fancy looking it over before the end of your week :)
[21:00] <slangasek> heh, I can do that. :)
[21:01] <A|i> would it be safe to install mysql-server-5.1 for hardy from jaunty repo?
[21:02] <slangasek> A|i: it has the general problems common to any installation of a newer package on an older system - untested, and you may have to upgrade an arbitrary number of other packages to get it to install
[21:02] <A|i> slangasek, my server is 8.04, and i cannot find any mysql 5.1 repo for it :/
[21:08] <slangasek> A|i: you could request a backport: https://help.ubuntu.com/community/UbuntuBackports
[21:09] <slangasek> personally, I think if you're going to bypass the integration and primary security support for the packages included in the LTS in order to get a newer version of a package as significant as mysql, you might as well upgrade the system to jaunty anyway
[21:10] <kees> A|i: you'd gain the default compilter flag improvements too
[21:10]  * kees is a broken record.
[21:19] <ScottK> A|i: I doubt we'd approve such a backport either.  mysql packaging isn't generally designed to be co-installable.  Jaunty has some changes for that, Hardy doesn't.
[21:20] <A|i> ScottK, how risky would it be to upgrade to jaunty from hardy on my server?
[21:20] <ScottK> A|i: Directly, don't do it.  Upgrade via Intrepid.
[21:20] <A|i> oh dear
[21:20] <ScottK> Hard to say for sure, but if you want 5.1, running Jaunty is your best bet.
[21:21] <ScottK> A|i: You don't intend to experiment with this on a production server do you?
[21:21] <A|i> ScottK, ii'm trying to install 5.1 manually, honestly it's a mess
[21:21] <A|i> even uninstalling mysql-server properly doesn't work fine
[21:21] <A|i> ScottK, it is a production one
[21:22] <ScottK> OK.  Experimenting on production boxes is just a recipe for tears.
[21:22] <ScottK> A|i: #ubuntu-server is probably a the best channel to seek help.
[21:22] <A|i> ScottK, it's an amazon ec2 instance, not really for production yet
[21:22] <ScottK> Ah.  OK.
[21:22] <A|i> good idea
[21:38] <slangasek> kirkland: hrm, why is /usr/share/doc/update-motd/changelog.Debian.gz missing?
[21:39] <jpds> Is there a why I can tell debuild to ignore the @*ubuntu.com Maintainer thing?
[21:40] <slangasek> jpds: it doesn't complain unless you put 'ubuntu' in the version number, does it?
[21:40] <slangasek> (if it complains for non-Ubuntu version numbers, you can file a bug and demand it be fixed ;)
[21:41] <jpds> slangasek: Yeah, it doesn't complain without ubuntu, but the Maintainer field is set to tha @canonical address.
[21:41] <cjwatson> if DEBEMAIL doesn't contain @ubuntu.com, then it's downgraded to a warning
[21:41] <cjwatson> so DEBEMAIL=jpds@someotherdomain.com debuild -S
[21:41] <slangasek> jpds: maintainer fields for packages in Ubuntu aren't supposed to be set to @canonical addresses...
[21:41] <cjwatson> that said it's probably silly for dpkg to complain about cases where they are
[21:42] <cjwatson> the point of that warning is to try to avoid people leaving the maintainer field set to the Debian maintainer's address, which we were explicitly asked by Debian not to do when making source changes
[21:42] <cjwatson> clearly not a problem for @canonical.com
[21:42]  * dupondje would like to know if somebody has coding experience with nautilus, as I have some question about a bug in it, which i'm fixxing
[21:43] <jpds> slangasek: Not my package (terminator)...
[21:44] <ScottK> Since it's just a warning, I just ignore it in cases it's not relevant (I don't change the maintainer in cases where I'm the Debian maintainer for example).
[21:44] <cjwatson> it's only just a warning because your DEBEMAIL doesn't contain @ubuntu.com
[21:44] <cjwatson> I suspect from the question that that isn't the case for jpds ...
[21:45] <cjwatson>                if (defined ($ENV{'DEBEMAIL'}) and $ENV{'DEBEMAIL'} =~ /\@ubuntu\.com/) {
[21:45] <cjwatson>                    error(_g('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address'));
[21:45] <cjwatson>                } else {
[21:45] <cjwatson>                    warning(_g('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address'));
[21:45] <cjwatson>                }
[21:45] <ScottK> cjwatson: That's correct.  I don't use my @ubuntu.com address, so the warning is correct.
[21:46] <cjwatson> I actually do change the maintainer even for my own packages these days, but I do that because that means queries about the Ubuntu version go to a different mailbox, which I find slightly useful
[21:46] <cjwatson> but not everyone does it that way ...
[21:57]  * slangasek files a fun bug on openssh
[22:00] <davmor2> slangasek: is it that it's not easy to say when drunk
[22:01] <slangasek> no, it's bug #400876
[22:02] <cjwatson> ... and it's time for me to head off for the weekend, amazing how that works
[22:02] <cjwatson> I can look at it on Monday if you want :)
[22:03] <slangasek> sounds good :)
[22:03] <slangasek> I'm not sure it's a terribly high-prio bug anyway
[22:03] <slangasek> not like there are lots of people who create .hushlogin and then later decide to remove it and are going to be upset about not seeing the legal disclaimer
[22:35] <slangasek> cjwatson, jpds: eglibc accepted (a bit ago) and building now, so perhaps we can test ia32-libs in a few hours
[22:35] <jpds> slangasek: Groovy.
[22:36] <elmo> is eglibc replacing glibc?
[22:37] <cjwatson> yes
[22:37] <cjwatson> it's effectively just a distribution of glibc
[22:37] <cjwatson> god, I *hate* the dialog-warning sound at the moment
[22:38] <cjwatson> mterry: so now that we have librelp in main (as of a few minutes ago, thanks to Kees' (tentative) signoff), I'm just about to seed rsyslog; I assume I might as well just do that rather than making you create a branch for a one-liner. :-) Any objections?
[22:39] <cjwatson> mterry: http://paste.ubuntu.com/220792/
[22:39] <elmo> I can't decide which upsets me more; the fact that throw-everything-away-screw-legacy keybuk is the guy as worried as me about eglibc becoming the default.  or the fact that eglibc is becoming the default
[22:39] <elmo> cjwatson: did they stregthen any of their API/ABI guarantees?
[22:39] <mterry> cjwatson, heh, actually I already did make the one-liner branch, but yeah, that'd be great (though you're patch isn't keeping the sort order!)  :)
[22:40] <cjwatson> verbally at least; the reason they don't give a strong one on the website is that they obviously aren't ABI-compatible if you disable option groups (facility provided by eglibc). We aren't doing that though, and they said they have zero interest in breaking ABI if you leave all the option groups on, and lots of pressure not to
[22:40] <cjwatson> if they add any interfaces of their own they'll use EGLIBC@blah versioned symbols
[22:40] <cjwatson> mterry: oh, let me grab that then
[22:41] <elmo> cjwatson: that still means we risk binaries that run on ubuntu/debian but not e.g. fedora, suse, though, right?
[22:41] <cjwatson> mterry: bleh, seeds are at best inconsistently sorted anyway :)
[22:41] <cjwatson> I think it's extremely unlikely
[22:41] <mterry> cjwatson, really the same thing, but here:   lp:~mterry/ubuntu-seeds/platform.karmic-rsyslog
[22:41] <cjwatson> I don't think they're remotely interested in doing that; if I catch a whiff of that I'll take action
[22:41] <kees> there, AppArmor now loads in under a second.  that should make Keybuk happy.  :)
[22:41] <mrooney> Hey, can anyone point me to the wiki page for package-specific upload rights? I'm trying to figure out if it is for me
[22:42] <cjwatson> (and it should be easy to check simply by seeing if any binaries use EGLIBC@ symbols
[22:42] <cjwatson> )
[22:42]  * elmo wanders off to practice his 'told you so' dance, just in case ;-)
[22:43] <mterry> elmo, you should really have that locked and loaded already
[22:43] <cjwatson> elmo: frankly I think we'll be considerably worse off if we have to maintain glibc ourselves without reference to Debian's packaging
[22:43] <jdstrand> kees: awesome!
[22:44] <cjwatson> mterry: ok, merged that, thanks
[22:44]  * cjwatson ponders the wisdom of a Friday evening ubuntu-meta upload
[22:44] <mterry> cjwatson, thank you.  I was worried I'd have to file a bug or harass someone
[22:44] <cjwatson> what could POSSIBLY go wrong
[22:44] <mterry> cjwatson, :)
[22:45] <ScottK> cjwatson: Nothing as long as you stay offline until Monday.
[22:45] <cjwatson> mterry: I assume we'll probably want to seed some of rsyslog's plugins as supported somewhere
[22:45] <cjwatson> or something
[22:45] <kees> jdstrand: just a few growing pains.  though your "it didn't cache anything" issue freaked me out.
[22:45] <mterry> cjwatson, hmm, you mean install some plugins by default?
[22:45]  * kees will pay money to see elmo's 'told you so' dance.
[22:46] <cjwatson> mterry: no, supported just means they go in main
[22:46] <mterry> cjwatson, right, but you said 'seed' and I got confused
[22:46] <cjwatson> the way it is at the moment, the maintenance scripts will be prompting us to put rsyslog-mysql etc. back in universe
[22:46] <cjwatson> supported is a seed ...
[22:47] <mterry> cjwatson, ah ah.  :)
[22:47] <cjwatson> not all the seeds are used for what's installed by default :)
[22:47] <jdstrand> kees: :)
[22:47] <cjwatson> (in fact, supported was one of the first three seeds)
[22:47] <cjwatson> (but it probably wouldn't actually want to go in supported, maybe server-ship or something)
[22:47] <cjwatson> or dvd or ... whatever
[22:48] <mterry> cjwatson, hmm
[22:48] <cjwatson> no rush, it won't fall out of main without manual action anyway
[22:50] <cjwatson> oh, blah, rsyslog needs to have its priority bumped before ubuntu-meta/update will pull it in
[22:50]  * cjwatson remembers about the weird special cases
[22:53] <cjwatson> mrooney: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package%20Uploaders
[22:58] <mrooney> cjwatson: that sounds perfect, thanks :)
[23:04] <cjwatson> StevenK: so is UNR all meant to be in main now? if so, I need to adjust component-mismatches
[23:07] <agent_j> i'm trying to package a game, but it doesn't work. do i compile the game and then make the package, or do i just make the package without compiling first?
[23:08] <cjwatson> your 'debian/rules build' ought to do any compilation required
[23:08] <ScottK> agent_j: #ubuntu-motu is a better channel for basic packaging questions.
[23:08] <agent_j> ok sorry