[00:52] <infinity> robert_ancell: Your gnome-icon-theme-symbolic wants a new gnome-icon-theme, which you didn't upload...
[00:54] <infinity> robert_ancell: (Causing an uninstallible cascade)
[00:55] <RAOF> Whee! 'tis the season for GNOME breakage, apparently.
[00:58] <infinity> AKA: Friday?
[00:58] <infinity> robert_ancell: Pls fix, thx. ;)
[00:59] <RAOF> There's also the new libgnome-desktop3, which broke soname but isn't parallel installable.
[00:59] <infinity> RAOF: Yeah, I know, I rebuilt the world to fix that already.
[01:00] <RAOF> Ah. That world-rebuild apparently hasn't made it all the way out to archive.ubuntu.com :)
[01:00] <infinity> Has too.
[01:00] <infinity> apt-get update harder.
[01:00] <infinity> Of course, you still can't upgrade smoothly because of the above icont-theme issue.
[01:00] <infinity> icon-theme, too.
[01:04] <RAOF> Oh! I don't have a.u.c in my sources on this install. That'd be why.
[01:05] <infinity> RAOF: Just some horribly lagging AU mirror of doom?
[01:05] <RAOF> Indeed.
[01:05]  * infinity used to have a love/hate relationship with iinet's mirror.
[01:05] <infinity> Loved that I got 24Mb/s from it.  Hated that it was always about 3.5 months out of date.
[01:05] <infinity> (That may be hyperbole)
[01:06] <RAOF> Internode's *generally* reasonably up to date.
[01:07] <infinity> Well, I only just fixed everything.  Being out by 30-60m seems acceptable.
[01:07] <ajmitch> 3.5 months sounds a lot like some NZ mirrors
[01:08] <infinity> My ISP's mirror here is lousy too, which is (one reason) why I just run my own.
[01:09] <mwhudson> i just use a.u.c :(
[01:10] <infinity> GigE to an internal mirror versus transatlantic link of ick that goes through a tiny router driven by a sickly hamster in the Netherlands...
[01:10] <infinity> I'll take the local mirror.
[01:15] <mwhudson> how quickly you forget the southern hemisphere :)
[01:16] <infinity> mwhudson: Thankfully, yes. ;)
[01:28] <infinity> robert_ancell: *poke, poke, poke, poke*
[01:43] <superm1> SpamapS: curious on your thoughts.  what about adding a dpkg trigger when new tzdata packages get installed to load the time zone data into mysql?  eg http://dev.mysql.com/doc/refman/4.1/en/mysql-tzinfo-to-sql.html
[02:04] <robert_ancell> infinity, hey
[02:12] <robert_ancell> infinity, so are we updating to quantal or quantal-proposed now?
[02:31] <ihashacks> Where might one go to report an error in the release blog? http://release-blog.ubuntu.com/?p=213
[02:32] <ihashacks> "Ubuntu 12.04 (Quantal Quetzal) Alpha 1 now available"
[02:36] <RAOF> Man. It took me three goes to work out what was wrong there :)
[02:38] <psusi> the numbers do sort of blurr together when you've been around for a while ;)
[02:38] <ihashacks> I guess since this next one isn't a "Pixel Perfect" release, details like that are negligable :-P
[02:39] <psusi> jesus... seems like a long way from 6.06 to 12.04, but feels like it was only yesterday
[02:40] <ihashacks> But, seriously, given that the blog isn't even "Ubuntu branded" I'm not sure anyone will even notice (although I did).
[02:40] <ihashacks> I just wanted to see who/how to notify so that it could be fixed.
[02:45] <cody-somerville> lol
[03:43] <cjwatson> ihashacks: I have access to that blog, but I don't seem to be able to edit other people's posts, so can't fix it directly.
[03:43] <cjwatson> skaet: ^- Please fix http://release-blog.ubuntu.com/?p=213 to say 12.10 rather than 12.04
[03:44] <cjwatson> (Both heading and body text)
[04:47] <SpamapS> superm1: seems like a pretty cool idea
[04:48] <SpamapS> superm1: Will have to think of what the ramifications might be, but all in all I think it would be a nice feature
[05:18] <skunk> cnd: are you there?
[07:00] <dholbach> good morning
[07:12] <didrocks> infinity: thanks for the unity upload. We are still fighting for a week on unity. I tried to port to boost, fix the build issues with gcc4.7, same code base, rebuilt libsigc++ with the quantal stack, and we still get some random crash at runtime…
[07:30] <dholbach> StevenK, happy birthday! :)
[08:23] <jamespage> Sweetshark, ping re libreoffice and switching dependencies from openjdk-6 to openjdk-7
[08:24] <Sweetshark> jamespage: pong, huh?
[08:24] <jamespage> Sweetshark, so I've been gradually shuffling through all of the dependencies on openjdk-6 in main
[08:24] <jamespage> libreoffice is one of the last two :-)
[08:27] <vibhav> Can anybody have a look at https://bugs.launchpad.net/ubuntu/+source/rofs-fuse/+bug/1010357 ?
[08:28] <Sweetshark> jamespage: well, im doing a libreoffice-3.6.0~beta1 upload (to ppa only right now). I guess there is enough trouble in a beta in itself to not mix in a java update. we could then upload a package just with the java update to see how much fun it breaks.
[08:28] <jamespage> Sweetshark, that would be great!
[08:29] <Sweetshark> jamespage: that being said, I cant do ~anything on quantal right now because of bug 1007616
[08:29] <micahg> Sweetshark: you can build with gcc 4.6 until that's fixed (and should)
[08:30] <micahg> jamespage: is there a release goal for quantal to drop openjdk-6 entirely?
[08:31] <jamespage> micahg, hmm - I'd like to but I think it more likely it will reside in universe for 12.10
[08:31] <jamespage> I think there will be some packages in universe we simply cannot transition at this point in time
[08:32] <micahg> jamespage: depending on what and how many, we could just drop and backport from R
[08:32] <jamespage> micahg, I think we can make a call on that later in the cycle depending on progress
[08:33] <micahg> yep
[08:33] <micahg> jamespage: if you have a guide for openjdk 7 porting, that might be good for MOTU opportunistic tasks
[08:34] <Sweetshark> micahg: oh, it seems I do now. I magically appeared in my rebase on debian after I told _rene_ about it ...
[08:34] <jamespage> micahg, emailed wed - https://lists.ubuntu.com/archives/ubuntu-motu/2012-June/007250.html
[08:34] <micahg> jamespage: ooh, thanks (I must have missed that)
[08:41] <vibhav> jamespage: Could you link me to the munin bug that I had to test?
[08:42] <jamespage> vibhav, sure - https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678
[08:42] <jamespage> much appreciated
[08:43] <jamespage> vibhav, as you seem to be very active with SRU's you might like these reports - http://people.canonical.com/~jamespage/server-sru/
[08:47] <vibhav> sure
[08:50] <vibhav> jamespage: Im getting http://paste.ubuntu.com/1030072/ , is that fine?
[08:52] <jamespage> vibhav, for a restart yes - but you need to check that the memory graph appears in the web interface to verify the SRU as per the test plan
[09:41] <vibhav> jamespage: From where can I reach the web interface
[09:42] <jamespage> vibhav: you should be able to see it on http://hostname/munin
[09:45] <vibhav> jamespage: would my.ip/munun work?
[09:46] <jamespage> vibhav, should do yes
[10:19] <doko__> Sweetshark, I would appreciate a bit more cooperation with issue 1007616, more than trowing mismatching bits over the fence
[10:23] <Sweetshark> doko__: what exactly do you need?
[10:24] <doko__> Sweetshark, do didn't build with 4.7, but with 4.6
[10:27] <Sweetshark> doko__: right, I have no quantal host right yet, as it is madness to try building LO on it at this point. But does the (4.6)-preprocessed stuff magically work now? If not, why cant you go hunting with it?
[10:28] <doko__> Sweetshark, so this neither built with 4.7 nor on quantal? what are you reporting then?
[10:28] <doko__> 1) On quantal
[10:28] <doko__> 2) with gcc-4.7-base i386 4.7.0-11ubuntu2
[10:29] <doko__> and no, I don't think it's madness after alpha1
[10:31] <Sweetshark> doko__: no, it doesnt build on 4.7 on quantal. It does build on 4.6 on precise. Thats it so far. Couldnt you do me the favour of throwing the (4.6/precise)-preprocessed input at 4.7/quantal quickly and see if it suicides gcc?
[10:32] <doko__> Sweetshark, it doesn't work this way. I need the preprocessed source with the 4.7 headers, not the 4.6 ones. sorry if that wasn't clear
[10:33] <Sweetshark> I will start to get my quantal pbuilder ready soon, but right now, I am still at getting 3.6.0~beta1 to build at all ...
[10:34] <Sweetshark> doko__: doh, I ignored that the headers are also compiler-dependant, yeah. ignorance is a bliss.
[10:35] <Sweetshark> doko__: I will try to get you a 4.7-preprocessed source one ASAP. Might take a while to get the pbuilder up though ...
[10:46] <xnox> Sweetshark: spin up a beefy machine on amazon cloud with quantal's alpha1 image and do a build there?
[10:46] <xnox> just to get the preprocessed source which fails
[11:09] <Sweetshark> hm, interesting something of starting virtualbox and unplugging the AC under some load was not appreciated by this machine ...
[11:09] <Sweetshark> OOM killed itself with a load average of >2000.
[11:23] <xnox> @pilot in
[11:23] <xnox> there are a couple of merge proposal's for usb-creator which are acient =)
[11:24] <ogra_> merge them into an ancient branch then :P
[11:28] <xnox> ogra_: haha =) I have lp:usb-creator commit rights so I will merge them into bleeding-edge branch =)
[11:30] <ogra_> evil, that might scare them :)
[11:30] <seb128> xnox, did you pick up usb-creator maintenance?
[11:31] <xnox> seb128: well ev is still the usb-creator overlord. Do you have anything in particular, that I can do as usb-creator's minion?
[11:31] <ogra_> seb128, well, after today he might be the last uploader :) we just need to make sure it stays that way
[11:31] <ev> xnox: I'm more than happy to pass the baton on that one
[11:32]  * xnox baton! baton!
[11:32] <ev> I've got way too many error tracker work items to give usb-creator any attention beyond code review
[11:32]  * xnox is reminded of Up!
[11:32] <seb128> xnox, no, mostly curious, we (desktop) were wondering if there was still any work going on it, especially that we go out of the CD size this cycle usb-creator might get an increased importance ... we were wondering if there was any design or tech work planned on it
[11:33] <seb128> ev, ^
[11:33] <xnox> I needs a refresh, yes =) but it does do the job out the box
[11:33] <xnox> s/I/it/
[11:33] <seb128> xnox, still it could do with some ui tweaks and some work
[11:33] <superm1> a few UDS's ago there was a session with discussion about things to improve with it that didn't all happen
[11:33] <ev> seb128: I didn't have anything planned. If there are specific needs, best to raise them with slangasek and then he can delegate
[11:33] <superm1> maybe brussels?
[11:33] <seb128> xnox, I was mostly wondering if anyone planned on that to not dup work if we plan to look at helping on it
[11:33] <ev> oh, that would be ace
[11:34] <seb128> ev, having design input would be nice, then we could probably help
[11:34] <ev> superm1: I vaguely recall that being the location
[11:34] <seb128> but I guess that's rather a mpt's question
[11:34] <ev> seb128: yeah, Matthew would be excellent for that when he's back from holiday
[11:34] <ev> as he designed the initial UI
[11:34] <seb128> ev, ok, so nothing done yet, I will check with him when he's back, thanks
[11:34] <ev> seb128: sure thing!
[11:34] <superm1> so if that old gobby doc is somwhere on the interwebs that might be a good starting point too
[11:35]  * ev lunches
[11:36] <xnox> superm1: please find it, it's before my time =)
[11:38] <seb128> xnox, you are supposed to get the knowledge of everything that happened in the past when joining!
[11:39] <xnox> seb128: I'm doing my best =) i have already picked up a lot, just not everything yet.
[11:39] <seb128> ;-)
[11:40] <xnox> I still get a twich when people mention 'oh yeah we fixed that in dapper'
[11:40] <superm1> xnox: actually you were in the IRC that day it looks: http://ubottu.com/uds-logs/archives/uds-m/%23ubuntu-uds-cocobolo-3.log
[11:40] <xnox> lol =)
[11:40] <superm1> gobby.ubuntu.com doesn't seem to respond to me
[11:40] <superm1> but http://paste.ubuntu.com/433382/ was captured before it crashed at some point during the IRC log
[11:41] <xnox> superm1: I think that got super-seeded by the amd64+mac iso
[11:41] <ogra_> seb128, we sadly forgot to give him the usual "La fusion mentale vulcaine" for new team members in SF when he joined
[11:41] <ogra_> -La i guess ...
[11:41] <seb128> lol
[11:43] <xnox> ogra_: "sometimes the recipient is supposed to be consenting if the merger may be experienced as a rape ."
[11:43] <xnox> http://fr.wikipedia.org/wiki/Fusion_mentale
[11:44]  * xnox *shrug*
[11:44]  * xnox moving on...
[11:44] <ogra_> you didnt read the fineprint in your contract, eh ?
[11:47] <xnox> ogra_: it does say "If ogra_ is speaking about you, using french terms, imediately report to your line manager."
[11:51] <ogra_> lol
[11:53] <xnox> superm1: https://wiki.ubuntu.com/DmitrijsLedkovs/usbcreatornotes#preview
[12:22] <ev> wow, and xnox is already speeding through usb-creator merge proposals. Rock on.
[12:23] <ev> xnox: on the automated tests front, do check out the usb gadget module in the kernel. It will let you write system tests without having to plug in a physical usb device.
[12:23] <ev> in response to your wiki page
[12:24] <xnox> ev: this ^^^ =) amazing, will look into that.
[12:24] <ev> awesome
[12:31] <vibhav> jamespage: ping
[12:31] <jamespage> vibhav, hey!
[12:32] <vibhav> jamespage: getting http://paste.ubuntu.com/1030293/ Is that fine?
[12:33] <jamespage> vibhav, not sure - is that coming from munin-node?
[12:33] <vibhav> No idea
[12:34] <vibhav> I cant browse to <IP_ADDRESS>/munin
[12:34] <vibhav> /window/window 28
[12:37] <scientes> DinstallException: 'Unknown distribution "unstable" in "/var/cache/archive/mini-dinstall/incoming/kyotocabinet_1.2.76-1_amd64.changes"'
[12:37] <scientes> im trying to use mini-dinstall
[12:37] <scientes> for cowbuilder
[12:37] <xnox> @pilot out
[12:38] <vibhav> Murphy's Law :(
[13:06] <seb128> could somebody reject https://code.launchpad.net/~mattmollett/ubuntu/oneiric/inkscape/fix-for-807861/+merge/109318 ?
[13:09] <Sweetshark> doko__: bug 1010468 now has everything you need.
[13:12] <vibhav> what does ld --as-needed exactly do to fix FTBFSes?
[13:14] <xnox> vibhav: it adds extra libraries to complete the linking
[13:14] <xnox> vibhav: http://wiki.debian.org/ToolChain/DSOLinking
[13:15] <vibhav> xnox: Is it applicable in debian too?
[13:15] <xnox> yes.
[13:15] <ogra_> (given the doc is on the debian wiki... )
[13:15] <xnox> it's not enabled by default, as far as I know, but the bugs themself are RC
[13:15] <xnox> vibhav: we want to use ld --no-as-needed by default =)
[13:15] <xnox> or the gold linker
[13:16] <vibhav> xnox: But why do some packges have a ubuntu delta which use ld --as-needed ?
[13:16] <vibhav> Instead of forwarding them to debian?
[13:17] <ogra_> slackish developers ?
[13:17] <xnox> vibhav: because we needed the package to build and adding --as-needed is not a proper fix
[13:18] <xnox> you generally have to modify autoconf/autotools/makefiles to add/remove required libraries in the correct order for the --no-as-needed link to succeed.
[13:19] <cjwatson> Uh, generally the Ubuntu delta is to tolerate a linker that defaults to --as-needed
[13:19] <cjwatson> Not to change ld's options to use --as-needed
[13:19]  * xnox says listen to cjwatson =)
[13:20] <cjwatson> We don't want to use --no-as-needed by default - that's backwards
[13:20] <cjwatson> See https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
[13:20] <cjwatson> Or better, http://wiki.debian.org/ToolChain/DSOLinking
[13:21] <cjwatson> (Ah, which xnox linked to above)
[13:22]  * xnox got the --no-as-needed and --as-needed backwards. --no-as-needed is bad as it's a workaround to revert to old/classic behaviour.
[13:22] <xnox> sorry
[13:22]  * xnox use gold, gold rocks =)
[13:23] <cjwatson> Shouldn't really need to nowadays
[13:23] <cjwatson> I was under the impression most of the gains there had been got by our default linker option changes
[13:24] <cjwatson> vibhav: The answer to why we have these as Ubuntu deltas is indeed generally just that nobody's got round to forwarding them yet, or they've been forwarded and not yet applied upstream of us
[13:28] <vibhav> ah
[13:28] <vibhav> ^^ was the answer I wanted
[13:29] <vibhav> thanks cjwatson
[13:29] <rbasak> "dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" - is there a way to override this? I'm preparing an SRU so presumably I want to leave that alone.
[13:30] <cjwatson> rbasak: Temporarily set DEBEMAIL to something that isn't @ubuntu.com when you run debuild -S
[13:30] <rbasak> cjwatson: interesting! Thanks :)
[13:31] <cjwatson> (You'll still get a warning, but it'll be downgraded from an error)
[13:33] <rbasak> That worked. But I just realised that this SRU is for a package without a previous ubuntu delta, so actually the error is right and I think I do want to run update-maintainer on it.
[13:35] <cjwatson> Agreed.
[13:35] <Sweetshark> cjwatson: since you raised your head on "--as-needed", could you shed some light on http://nabble.documentfoundation.org/make-check-problem-in-libtest-smoketest-building-master-td3902404.html#a3905049 ?
[13:36] <rbasak> Thanks. I'll pay more attention to the changelog in future.
[13:36] <didrocks> bdmurray: hey, are you running a script for dup detection? There are some wrong test cases in bug #1010239. In addition, if I deduped, your script reduped it
[13:37] <Sweetshark> cjwatson: esp. with regards to "Fedoras implicitDSO is sane, what Debian/Ubuntu does is not" ...
[13:37] <didrocks> bdmurray: but the first dup was wrong: it's crashing calling the same functions, but the stack is different and the first bug was "fixed released" in september 2011. So dupping it shouldn't happen for regressions anyway
[13:38] <cjwatson> Sweetshark: Not really, -> doko
[13:39] <cjwatson> Though from that thread it sounds like you probably just want to add --no-as-needed to LDFLAGS or similar and get on with your life
[13:39] <cjwatson> We're not going to revert the toolchain change again, AFAIK
[13:39] <Sweetshark> cjwatson: ;)
[13:41] <cjwatson> We reverted it for natty because it broke too many things, but enough of them were fixed for oneiric that we were able to leave it on; it has substantial global benefits and it makes sense for us to have it as a default and for the small minority of packages that can't cope to deal with it
[13:41] <Sweetshark> cjwatson: I dont have a problem with release builds (I reordered some lib or did --no-as-needed), but it is highly annoying for new contributors who cant compile an unpatched LibreOffice once in a while ...
[13:41] <cjwatson> If LO assumes --no-as-needed I don't see why they can't just add that
[13:42] <cjwatson> Having it on by default in the distribution makes it much easier for us to avoid problems with excessive indirect linking
[13:42] <cjwatson> And in any case I don't believe we're the only ones - OpenSUSE did this before us, I think
[13:43] <Sweetshark> cjwatson: LO depends on --no-as-needed being the default, but locks down to --as-needed in some places IIRC.
[13:44] <cjwatson> It's silly of them to depend on that but refuse to be explicit about it.
[13:45] <Sweetshark> cjwatson: having said that, it currently works, but some unsuspecting commit from other distro might break it again once in a while causing some useless discussion then ...
[14:00] <seb128> could somebody reject https://code.launchpad.net/~mattmollett/ubuntu/oneiric/inkscape/fix-for-807861/+merge/109318 ?
[14:03] <jamespage> vibhav, can you take me through what you have done so-far?
[14:13] <vibhav> jamespage: Are you talking about munin?
[14:13] <jamespage> vibhav, yes - sorry - a bit async + lag today
[14:20]  * xnox_ smuxi fail =(
[14:38] <vibhav> jamespage: I still cant get to <IP_ADDRESS>/munin
[14:39] <vibhav> And the log is the same
[14:39]  * vibhav suspects its something to do with his desktop
[14:39] <vibhav> Could you try it on your computer?
[14:39] <jamespage> vibhav, I can - are you following the test case in the SRU?
[14:41] <vibhav> jamespage: yeah
[14:41] <jamespage> vibhav, OK - lemme take a look
[14:41] <vibhav> thanks
[14:46] <jamespage> vibhav, OK I tweaked the test plan slightly - all you should need todo is install the packages - just tried it on a fresh install and it worked fine
[14:46] <jamespage> can see memory data and everything
[14:47] <bdmurray> didrocks: it was an old bug pattern that was causing the duplicate detection.  I'll look at cleaning up old ones.
[14:48] <\sh> moins
[14:49] <didrocks> bdmurray: thanks!
[14:50] <vibhav> jamespage: So the verification is done?
[14:55] <vibhav> Could anybody have a look at https://bugs.launchpad.net/ubuntu/+source/rootskel/+bug/1010506 ?
[14:55]  * xnox hates bug 762193
[14:57] <cjwatson> vibhav: You should ask the person who touched the package last before merging stuff
[14:58] <cjwatson> vibhav: In the case of rootskel it's much harder to apply a debdiff than to just do the merge in our bzr branch
[14:58] <cjwatson> And your changelog is wrong - would you mind awfully if I just did this myself? :-)
[14:59] <cjwatson> vibhav: FWIW I hadn't bothered to merge rootskel because the changes in that Debian upload have precisely zero effect on Ubuntu
[15:03] <jamespage> vibhav, not really - I did the fix :-) I want someone else to check my work....
[15:03] <seb128> xnox: do you get that bug often? I never saw it and I use xchat-gnome every day
[15:04] <seb128> xnox: do you use the SRU version of unity?
[15:04] <xnox> seb128, i am enjoying it *right now* on quantal =) with xchat-gnome with the xchat-gnome-indicator
[15:04] <seb128> xnox: i.e did you restart since 5.12-0ubuntu1.1
[15:05] <seb128> xnox: quantal didn't have the SRU fixes until recently, it was failing to build with the new toolchain, then they did hit a segfault due to c0xx behaviour change with signal they just tracked down today
[15:06] <xnox__> seb128, so xchat & xchat-indicator work like a charm. xchat-gnome & xchat-gnome-indicator are borked for now. Let me upgrade 200 packages (3 minutes)
[15:06] <seb128> ok
[15:07] <seb128> xnox__, you probably have an unity update in those packages?
[15:26] <vibhav> cjwatson: Sure! Go ahead
[15:38] <ritz> xnonx_ seb128 will probably roll in the indicator into the main package itself
[15:38] <ritz> wrt xchat-gnome
[15:38] <seb128> ritz, you will do that upstream for it?
[15:39] <ritz> yes, need to rewrite the converstaion panel into something more modern. Will be checking up on webkit this weekend
[15:40] <seb128> ok
[15:40] <ritz> once this is done, plan to ensure a higher degree of ubuntu integration
[15:42] <xnox> ritz: yes please =) and no assumptions that 'minimise to tray' is (a) available (b) is the right thing to do
[15:43] <ogra_> ++
[15:44] <ritz> no more minimise to tray
[15:45] <ritz> not a valid concept in gnome shell
[15:45] <ritz> and for unity, I prefer the close window to hide the client
[15:46] <ritz> xnox , again , this is my belief . If you feel otherwise, feel free to post to https://live.gnome.org/Xchat-Gnome
[15:46] <ritz> pretty much a very rough draft
[15:46] <xnox> ritz: hiding is fine =) as long as the icon stays in the unity dash and the alt-tab
[15:47] <ritz> hmmm
[15:48] <ritz> interesting. I was thinking more along the lines of emapthy
[15:53] <xnox> ritz: i see. close to hide and no icon in dash. minimise to hid and have icon in the dash. would work for me. but's it's just me. I have IRC full screen and open anyway and I switch between  different apps
[16:54] <dobey> not cool
[16:55] <ogra_> warm then ?
[17:00] <barry> stgraber: i'd like to upload the pydbus fix for bug 1008898 now.  will you revert the ubiquity workaround once that lands?
[17:02] <dobey> ogra_: trolls are proabbly cold blooded. and don't know why else you'd get that many Excess Flood kills :)
[17:02] <ogra_> heh
[17:03] <ogra_> well, your client should allow you to ignore join/part if it really annoys you
[17:03] <stgraber> barry: yep, I can do that. Having the fixed python3-dbus won't break ubiquity anyway but we certainly shouldn't keep the hardcoded signature :)
[17:04] <barry> stgraber: :)
[17:04] <barry> stgraber: uploaded
[17:07] <dobey> ogra_: i'm sure it does, but then i'd also miss seeing the ones i care about :)
[17:07] <ogra_> heh, yeah
[17:07] <ogasawara> @pilot in
[17:10] <infinity> @pilot in
[17:11]  * infinity hopes ogasawara doesn't push him out of the topic.
[17:11] <ogasawara> infinity: heh, it wouldn't be the first time I've pushed you
[17:12] <infinity> ogasawara: That was my point entirely.  Meanie. ;)
[17:12] <ogra_> infinity, well, at least she doesnt steal your pings !
[17:13] <ogasawara> man, rough crowd today! :)
[17:13] <ogra_> :)
[17:13] <infinity> ogra_: That kinds seems like a feature.
[17:13] <infinity> ogasawara: You're welcome to steal my pings anytime.
[17:13] <ogra_> its also the "thank you " ones !
[17:13] <infinity> ogra_: No one ever says that to me.
[17:13] <ogasawara> heh
[17:14] <ogra_> ogfinity, thank you !
[17:14] <ogfinity> ogra_: Note that "gee, thanks" isn't actually the same as "thank you".
[17:48]  * Sweetshark lols at backlog.
[20:17] <cr3> is there a plan to remove perl from the desktop image during the quantal cycle?
[20:25] <slangasek> cr3: no... are you expecting there to be?
[20:28] <cr3> slangasek: I thought I'd heard something to that effect, just checking whether it was my imagination :)
[20:28] <slangasek> cr3: you may have misheard 'python2' as 'perl'?
[20:29] <cr3> slangasek: nah, that one is already well underway on my side. by the way, I vaguely recall there being a 2to3 sprint of some sort either next week or the week after, is that my imagination again?
[20:30] <slangasek> we're having a virtual sprint next week in #pyjam
[20:30] <slangasek> Mon-Wed
[20:32] <cr3> slangasek: cool, most of checkbox was converted to python3 this week. would it help if I pushed those changes in ubuntu as early as possible?
[20:32] <slangasek> cr3: in the general release-early-and-often sense, yes
[20:32] <slangasek> we're certainly ready to receive python3 apps on the desktop in quantal
[20:35] <cr3> slangasek: I was wondering more in the pyjam sense. there are a few standalone scripts that haven't been converted yet, but all the core of the project has been converted. so, perhaps being able to calculate the overall dependencies of the desktop image with one more app converted might be useful
[20:35] <cr3> s/overall dependencies/overall python 2 dependencies/
[20:40] <slangasek> cr3: the list of todos is still long enough that it's unlikely to register :)
[20:41] <cr3> slangasek: ok, I'll try to push the changes in the release-early-and-often sense then :)
[20:41] <cr3> someone in the core devs is not going to be happy reviewing the mega changes :0
[22:03] <infinity> @pilot out
[22:04]  * infinity stops maintaining the fiction that he's piloting, when the piloting he's doing will go into the weekend with glibc upstream...
[22:07] <xnox> infinity: well done =)
[22:09] <infinity> xnox: Yeah, I do so love it when I pick bugs to work on that make me don a community hat over the weekend. :P
[22:09] <infinity> xnox: At least I won't be bored, right?
[22:09] <xnox> true =)
[23:27] <hippiehacker> Is there anything newer than https://help.ubuntu.com/community/LiveCDCustomizationFromScratch for creating 12.04 iso's from scratch? Is it still pretty much the same process?
[23:33] <xnox> hippiehacker: better suited for #ubuntu-installer but yeah I believe that still more or less the same.


[05:01] <Eickmeyer[m]> OvenWerks: Seeing a lot of activity in the -controls front. Need a pre-release upload somewhere?
[05:03] <OvenWerks> I would certainly like it tested :)  but there are a few things I have thought of since uploading.
[05:04] <OvenWerks> I have hard coded the version into convert-* and it is probably the wrong version. I would like to have one place I can put the version and have everything refer to it
[05:22] <OvenWerks> so after rebootingone of my problems goes away. I guess some upgrade in the past week or so... or maybe because it was the first power up after a hydro blackout
[05:23] <OvenWerks> Eickmeyer[m]: there have been major changes with this last upload. As you know, I changed the whole paramter storage setup from before and there are a lot of new lines of code and edited lines.
[05:24] <Eickmeyer[m]> OvenWerks: Ok, I think I might throw it into autobuilds or something if you want to do a tag.
[05:30] <OvenWerks> Eickmeyer[m]: I think I will do one or two more things first. Update the ping version so a newly downloaded package will force restart autojack for one.
[06:07] <OvenWerks> Eickmeyer[m]: ok, Tagged.
[06:14] <OvenWerks> Eickmeyer[m]: umm.. I think the makefile may need convert-studio-controls added :P
[06:15] <OvenWerks> nope
[06:15] <OvenWerks> it is there we install usr/bin/*
[06:25] <OvenWerks> yikes around 2000 lines of code... might be some bugs
[07:23] <OvenWerks> Eickmeyer[m]: bug fix already.
[16:07] <Eickmeyer[m]> OvenWerks: Ok. I'll see what I can do about getting this up and tested. :)
[20:12] <Eickmeyer[m]> OvenWerks: Yeah, it's got an issue, at least on my system. I have a usb midi controller that has no stream0 (since no sound) and it
[20:12] <Eickmeyer[m]> 's throwing an error because stream0 is assumed, apparently.
[20:12] <Eickmeyer[m]> So, issue #32.
[20:30] <Eickmeyer[m]> Sorry, #33.
[21:08] <OvenWerks> Eickmeyer[m]: ok.
[21:10] <OvenWerks> that sounds odd. Normally if there are no capture/playback devices we don't call it a device ;)
[21:11] <OvenWerks> but first... the whole extra devices tab doesn't work :P
[21:13] <OvenWerks> I did try plugging in a USB MIDI device and didn't see that.
[21:19] <OvenWerks> Eickmeyer[m]: please do not merge people's fixes for controls right now.
[21:20] <Eickmeyer[m]> OvenWerks: Ok, sorry about that.
 *hands Eickmeyer the big red stopsign*
 :P
[21:21]  * Eickmeyer[m] salts @teward001
 too late i'm already consuming salt.  *points at the IV drip of saline water going into his veins*
 had to go to the medihelp urgent care nearby for dehydration.  they hooked up the IV in me.
 registered nurse and doc all signed off on it.  And it's just water so :P
[21:36] <OvenWerks> Eickmeyer[m]: I am still finding myself doing a number of changes and other changes to the same file make rebase fail and require manual edits
[21:36] <OvenWerks> I think that one will be ok as happens.


[08:22] <ppisati> morning *
[08:23] <smb> morning
[08:25] <abogani> morning
[08:27]  * jk- tips hat
[08:28] <smb> jk-  is wearing hat in summer? ;)
[08:28] <iceroot> we have a working patch for this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502
[08:28] <jk-> there are hats for all seasons!
[08:28] <ubot2> Launchpad bug 869502 in linux "Kernel-Panic with <IP_ADDRESS>-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
[08:28] <iceroot> what is the common way? wating until it is upstream? or directly patching ubuntu-kernel?
[08:30] <smb> iceroot, Usually the preferred way is to at least wait until it appears upstream, yes. On critical issues that may be accelerated, if it looks like the maintainer is ok with it.
[08:31] <iceroot> smb: ok
[08:32] <smb> If you send an email that points to the patch, gives some background where it comes from and what the upstream status is to kernel-team mailing list (and for what release it is) it is possible to look at it
[08:32] <iceroot> smb: so kernel-team is normally "only" reacting on mails not on launchpad-bugs?
[08:32] <iceroot> ubuntu-kernel-team
[08:33] <smb> iceroot, It is simpler because bug email just floods in. Easy to miss things there
[08:33] <smb> If there is a single developer already assigned, then its a bit different
[08:34] <iceroot> smb: thank you for the info, i will send a mail to last list
[08:34] <smb> iceroot, Thanks
[08:49] <apw> alexbligh, ahh yes it is possible we moved to linux, following linus
[08:49] <apw> alexbligh, i must admit my personal linux-linus tree i use for close bases is taken from kernel.org
[08:51]  * apw yawns
[08:54] <jk-> ey apw
[08:54] <apw> jk-, dude
[09:16] <ppisati> who decides which pkg go into a release? i mean
[09:16] <ppisati> the preinstalled image for omap4 from friday is stil using the onerici kerne (<IP_ADDRESS>)
[09:17] <ppisati> while P/master has moved to...
[09:17] <ppisati> 3.2.x
[09:17] <ppisati> to whom shall i talk?
[09:18] <ppisati> BTW 3.0.0.x has bug for the beagle xm rev c (and the same bug doesn't show up on latest kernel that's why i would like to use an updated kernel)
[09:18] <ppisati> and there's no ogra around when you need one...
[09:18] <ppisati> :)
[09:31] <apw> smb, yeah we don't have lbm yet, and won't for some time i suspect
[09:32] <apw> will confirm it is turned off in meta, which it should be, and probabally let leann make it
[09:32] <smb> apw, Ah ok. Makes sense.
[09:41] <jibel> we get bug 894768 during automated iso testing of Precise images. Could one have a look ?
[09:41] <ubot2> Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [Undecided,Incomplete] https://launchpad.net/bugs/894768
[09:49] <smb> jibel, I try to look into it. There are not too many kernel errors on a quick first glance, though. Btw, do you know what xvda2 should be? extended partition?
[09:53] <jibel> smb, correct, extended partition.
[09:54] <smb> jibel, ok thanks. Was one message I did see. But that being unknown type for the os prober sounds ok
[10:04] <brendand> apw - hi
[10:05] <apw> brendand, HI
[10:06] <brendand> apw - have you been following : https://lists.ubuntu.com/archives/kernel-team/2011-November/017938.html ?
[10:12] <apw> brendand, i have seen some of the discussion yes
[10:13] <brendand> apw - any thoughts on what could be left out of the list?
[10:16] <apw> brendand, i think the dimensions shown make sense, video, audio, webcam, etc
[10:17] <apw> brendand, those seem to be the ones we'd have an issue against, perhaps video(ati) video(intel) might be useful
[10:17] <apw> brendand, beyond that i think you are talking specific devices, and only a full list is of use
[10:17] <apw> (not sure if that answers what you are asking)
[10:19] <apw> brendand, the things which seem to be 'x' seem uninteresting in the main, perhaps some of the touchpads are interesting, but again most likely i care about one specific one
[10:21] <brendand> apw - but is it worth testing all of the different touchpads in general?
[10:25] <apw> brendand, i read teh email as asking about categories one might with to test against, so "i have a patch which does this can you test it on as many relevant machines"
[10:26] <brendand> apw - so, the scope of this is that we come up with a list of device categories for which we want at least one system with each device of that category in our testing pool
[10:27] <apw> is this a pool of machine to automatically test against?
[10:27] <apw> if so then no input device is relevant i guess
[10:28] <brendand> apw - best to assume they could also be manually tested
[10:29] <apw> the problem with both touchpads and wifi, is there are 100s of each, you're not going to cover the whole spectrum
[10:29] <brendand> apw - no, but we can test all the ones we have in house
[10:30] <brendand> apw - take a 'Memory controller' for example. would we ever want to be testing each different memory controller?
[10:31] <apw> brendand, memory controllers are so tied to the CPU type (being built in these days) that you'd more want a range of "platforms", ivybridge, sandybridge, whatever amd calls things
[10:31] <apw> (and those are all X on the list already)
[11:06] <Q-FUNK> Could the fix provided in bug #892615 please be merged?
[11:06] <ubot2> Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615
[12:29] <apw> BAH I hate it when people ask things and then go away
[12:29] <apw> q-funk, we are waiting for someone in the know to ack that the patch is safe for non-geode h/w
[12:29] <apw> (not that you will see my reply)
[12:30] <_ruben> can't really blame him for pinging out.. ;-)
[12:31] <_ruben> well, you can, but might not be fair
[13:54]  * cking needs to reboot
[14:10] <ogasawara> apw: thanks for uploading -rc3 and linux-meta
[14:11] <tgardner> ogasawara, speaking of uploads, whats going on with armhf?
[14:12] <ogra_> tgardner, we would like to have the entries in debian/control soon :)
[14:12] <ogasawara> tgardner: I believe apw was fixing up the control file
[14:12]  * ogra_ doesnt think any additional stuff is required atm ... we dont have the builders running yet
[14:13] <tgardner> ogra_, are there functional chroots for armhf yet ?
[14:13] <ogra_> not sure, last update from infinity i had was friday, saying the chroots should be ready and are pending launchpad enablement
[14:14] <ogra_> (which still might take some days)
[14:14] <tgardner> ogra_, ok, I was just noticing uploads from him referencing armhf
[14:14] <ogra_> right, we need to make the packages that dont have hf as target arch in debian/control aware of that arch
[14:15] <ogra_> theye uploads are mainly doing that one line change i guess
[14:15] <tgardner> ogra_, right, I don't think its too complicated.
[14:16] <ogra_> well, for kernels this is generated, isnt it ?
[14:16] <ogra_> i.e. you need to duplicate the config etc
[14:16] <tgardner> ogra_, yes, but its mostly scripted.
[14:16] <ogra_> yeah
[14:17]  * herton -> lunch
[14:17] <ogra_> but still a bit more than doing s/armel/armel armhf/
[14:17] <tgardner> indeed
[14:34] <tgardner> cjwatson, if we switch the kernel to 'Depends: crda (>= 1.1.1-1ubuntu2)', can you deal with the main inclusion carnage ?
[14:35] <tgardner> p.s. - thanks for fixing the file collision between crda and wireless-regdb
[14:41] <apw> ogasawara, no problem, best to get it done early
[14:41] <apw> ogra_, i worked with infinity this am to add the armhf stuff; and to tell him about DEB_STAGE1 which he wasn't using
[14:41] <apw> tgardner, ^^
[14:42] <tgardner> apw, ack.
[14:42] <apw> ogra_, all the config bits were already in it was just the control file change which was missing
[14:43] <ogra_> ah, cool
[14:44] <apw> ogra_, in theory we are there, infinity is also going to play with the staged stuff for future
[14:44] <ogra_> yeah, i'm personally more concerned to get the buildds up, armhf *can* run with armel kernels ... its just for getting a properly named deb in the archive
[14:46] <Q-FUNK> ogasawara: could the fix to bug #892615 please be merged?
[14:46] <ubot2> Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615
[14:46] <ogasawara> Q-FUNK: I'd like to get more testing on non-geode hw first and I would prefer to see it getting applied upstream as well.
[14:59] <brendand> sconklin - hi
[15:00] <sconklin> brendand: good day
[15:04] <brendand> sconklin - we're looking at an issue with the Lucid -proposed kernel at the moment. afraid we don't have an awful lot of detail right now though
[15:05] <brendand> sconklin - we have a server system which was certified with 10.04.3 and now it's halting shortly into testing
[15:06] <jsalisbury> op jsalisbury
[15:06] <tgardner> brendand, its bjf and herton problem now. have you been able to get a dmesg trace ?
[15:06] <sconklin> brendand: While I care (really!), bradf is the stable kernel manager as of UDS - I am doing a rotation in QA. herton is also doing a lot of the stable work
[15:06] <jsalisbury> ogasawara, do you know how I get the permissions to become operator, so I can change the channel topic?
[15:08] <ogasawara> jsalisbury: hrm, I can't remember the exact process bjf, apw, and I went through to get ops.  let me try and dig for more info.
[15:08] <jsalisbury> ogasawara, thanks
[15:08] <apw> hrmmm i think we started out asking is
[15:09] <brendand> sconklin - ah, i didn't know that
[15:09] <apw> somehow our channel isn't one of the officially owned ones (an oversight) so it was less straight forward
[15:10] <ogasawara> jsalisbury: I've gone ahead and updated the topic for you in the mean time
[15:10] <jsalisbury> ogasawara, cool, thanks
[15:29] <herton> brendand, is it a new issue (are you able to freeze the machine with previous kernel, or only on the new kernel?)
[15:30] <brendand> herton - as far as we can tell, only with the new kernel. we don't know yet does it happen randomly or whether a test is triggering it
[15:31] <brendand> herton - unfortunately the system is in taipei and i don't have access so can't do any investigation right now
[15:32]  * ogasawara back in 20
[15:33] <herton> brendand, ok, would be good if someone is able to check which test freezes, and if there is some oops or other reason for the freeze. May be a bisect will be needed to check what introduced the problem.
[15:33] <cjwatson> tgardner: I already dealt with the main inclusion carnage :-)
[15:34] <tgardner> cjwatson, cools. thanks.
[15:34] <cjwatson> tgardner: mainly by taking the Gordian-knot approach; it's clearly a one-for-one replacement for wireless-crda, so I just promoted it, in trust that wireless-crda will fall out soon enough
[15:34] <tgardner> I'll make the change in the ekrnel.
[15:34] <cjwatson> that should be fine - the Provides should ensure that old and new kernel packages are still coinstallable
[15:35] <cjwatson> it'll have the effect of forcing everyone over to crda, which is what we want anyway
[15:38] <tgardner> cjwatson, hmm. this will essentially prohibit running a precise kernel in older user spaces if I make it absolutely dependent on crda.
[15:40] <tgardner> maybe I'll leave it 'Depends: wireless-crda | crda' for now.
[15:46] <brendand> herton - ok. we'll do more investigation when our lab engineer returns tomorrow morning and keep things up-to-date. when i have a bug number i'll add it to the tracking bug.
[15:48] <herton> brendand, ack
[15:49] <cjwatson> tgardner: you could flip the dependencies round to indicate the current preference
[15:49] <cjwatson> tgardner: although that probably won't cause apt to replace with the newer code
[15:50] <tgardner> cjwatson, I was just gonna ask if ordering had an impact.
[15:50] <tgardner> if we drop wireless-crda from precise, then dpkg should always select crda, correct ?
[15:59] <cjwatson> tgardner: for new installations, yes; that won't cause apt to remove wireless-crda on upgrades, though
[15:59] <cjwatson> (it might persuade update-manager to do so)
[16:01] <ppisati> if i bump the abi, does it fix the missing module case too? i guess it won't...
[16:01] <tgardner> cjwatson, ok, I'll start a bug against update-manager so we don't forget this. since wireless-crda will no longer be maintained, I'd like for it to get removed on upgreade.
[16:01] <tgardner> ppisati, nope.
[16:02] <tgardner> ppisati, add an ignore.modules to the ABI directory
[16:02] <ppisati> and i bump the abi too, right?
[16:02] <cjwatson> tgardner: update-manager is the wrong place to fix this - if you want to get rid of it, there needs to be a Conflicts: somewhere
[16:02] <tgardner> ppisati, thats not necessarily related. you can drop modules without changing the ABI
[16:03] <ppisati> ok
[16:03] <cjwatson> it's unfortunate that crda was uninstallable in oneiric
[16:03] <tgardner> cjwatson, but that affects the ability to run precise kernels in older user spaces.
[16:03] <cjwatson> I know, but still, fixing it in update-manager is an absolute last resort
[16:03] <cjwatson> let's not start there
[16:04] <tgardner> cjwatson, ok, I'll just leave it be for now. if I see a big crda update I'll consider updating wireless-crda
[16:04] <tgardner> I did swap the order so that crda is preferred
[16:04] <cjwatson> nothing springs to mind right now, but there may be some tricky way to conflict such that it goes away on precise upgrades but doesn't break older userspaces
[16:05] <cjwatson> most things are possible somehow :)
[16:05] <tgardner> yeah, yuo'd think this situation has been encountered before
[16:05] <cjwatson> we could even SRU wireless-crda to add a crda transitional package or something
[16:05] <cjwatson> kind of the reverse of the usual transitional package situation
[16:06] <cjwatson> hm, except that doesn't quite work
[16:06] <tgardner> cjwatson, perhaps turn the preicse version of wireless-crda into a meta package  that depends on crda ?
[16:06] <cjwatson> oh, yes, of course, that's the simplest answer isn't it
[16:06] <tgardner> ok, I can do that
[16:07] <cjwatson> yeah, I recommend that
[16:07] <tgardner> ogasawara, can you get that on our list of things to do ?
[16:07] <ogasawara> tgardner: yep
[16:07] <cjwatson> maybe crda (>= 1.1.1-1ubuntu2) to make sure we don't get bitten by the uninstallability in oneiric
[16:08] <tgardner> cjwatson, already done for the kernel. I'll do the same for wireless-crda
[16:08] <cjwatson> (crda depended on wireless-regdb but they shipped a common file)
[16:08] <cjwatson> great
[16:10] <Q-FUNK> ogasawara: there won't be much testing taking place for as long as it's not applied to something that it pushed into the repository...
[16:11] <ogasawara> Q-FUNK: I'll be testing locally
[16:35] <Razec> Hi guys...
[16:35] <Razec> I want to get involved in the Ubuntu Kernel Development. What steps do I take to get involved?
[16:38] <Q-FUNK> ogasawara: I assume that we're talking about that one-line fix, mentioned in the bug, that applies the feature only to recent AMD hardware?
[16:57] <apw> ppisati, hey, whats the gen on this omap issue, display driver, we know what needs changing
[16:58] <apw> ppisati, and is this ti-omap4 ?
[16:58] <ogasawara> apw: ah, I see he's sent a patch to the ml
[16:59] <ogasawara> ppisati, ogra_: I assume this need uploading asap
[16:59] <apw> ogasawara, assuming the release team say yes of course :)
[16:59] <ogra_> ogasawara, agreed ... its just a one option config change in the arm config though
[17:00] <apw> ppisati, and we have tested this yes?  we know the kernel with just htat option is GOOD
[17:00] <apw> ogra_, has anyone tested with the option on, to make sure thats the only change
[17:00] <ogra_> apw, its not working at all without it
[17:00] <apw> ogra_, and if changging it doesn't make it work there is no point in uploading and disrupting all the other architectures
[17:00] <ogasawara> from ppisati -> "Tested on my Beagle XM."
[17:00] <apw> so ... has anyone tested it does work
[17:00] <ogra_> there is a new display driver thats being used by linaro already, we just didnt enable it in our config
[17:01] <ogra_> well, we enabled it as module which apparently doesnt work at all ... so it needs =m to become =y
[17:01] <ogra_> and given the old display driver is gone in favor of the new one ....
[17:01] <apw> yep new things become =m by default, if they can be, one assumes they work if they say they can do =m, sigh
[17:02] <ogra_> well, its TI ....
[17:05] <l3on> Hi all... does someone know why we don't have a linux image 3.2-rc3 in http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
[17:05] <apw> ogra_, if this patch is accurate, the issue has existed in all the 3.2-rc kernels, ie been in the archive for weeks how have we missed this till today
[17:06] <ogra_> apw, not much testing yet i guess
[17:06] <apw> ogra_, if we don't care enough to test it, why are we spinning for it
[17:07] <ogra_> apw, we do, but the last weeks were filled with paperwork and vacations
[17:07] <ogra_> and we are not used to have images before A1 at all
[17:07] <ppisati> apw: i just noticed this morning, because i was installing the new preinstalled image from 28th
[17:07] <ogra_> thats a total novum
[17:07] <ppisati> apw: the omap images till 25th had a 3.0.x kernel still
[17:08] <ppisati> friday i tried a nioghtly build, and it still had the 3.0 kernel
[17:08] <ppisati> the funny thing is that i was looking to fix another bug... :)
[17:08] <apw> ppisati, hmm, how can that be i wonder, we've had 3.2-rc2 in there for ages
[17:09] <ppisati> apw: dunno
[17:09] <ppisati> apw: this morning, in this channel, i asked how the images are built
[17:09] <ogra_> meta having been stuck somewhere without anyone noticing ?
[17:09] <ppisati> apw: who decides which pkgs go in evbery image
[17:09] <ogra_> ppisati, the meta package
[17:10] <ogra_> live-build pulls in linux-omap by default for the omap image
[17:10]  * apw is baffled
[17:11] <ogra_> so it might be that linux-omap sat in binary new and nobody noticed or that it accidentially went to universe once again and nobody noticed
[17:11] <ogra_> though i had someone last week on IRC who actually complained about the orange screen you were seeing too, but i was swamped in sorting team specs
[17:12] <ogra_> so i didnt dig into it
[17:12] <apw> ogra_, maybe universe, thats been a common problem recently
[17:13] <ogra_> yeah, one of the two isuues are the usual ones
[17:13] <apw> ogra_, yeah so i think the kernel was out, so installs should have gotten it
[17:13] <apw> i suspect we have another issue in image build
[17:13] <apw> oh well
[17:13] <ogra_> well, we'll do better next time
[18:15] <GrueMaster> apw: As to testing, it comes down to man power.  AFAIK, I am the only one really doing any image testing on daily armel images.  I am also the only one testing SRU kernels on armel.  I am also the only one doing major armel server test automation.  I need more of me.
[18:15] <apw> yeah we need more testing power
[18:17] <GrueMaster> afaik, the testing that linaro does on the kernels is limited to mainly headless automation (I could be wrong, but given the hardware, I doubt it).
[18:24] <apw> ogasawara, i've added a annotation for the arm DVI thingy
[18:24] <ogasawara> apw: ack
[18:27]  * apw wanders to make some food ...
[18:48]  * tgardner follows suit -> food
[19:01] <cking> hrm food
[19:21] <apw> cking, yeah food
[19:21] <cking> yum
[19:27] <herton> apt
[19:34] <apw> tsk
[19:40] <cking> sigh
[20:00] <rik_> sforshee: can I ask you a question regarding bug 606238?
[20:00] <ubot2> Launchpad bug 606238 in linux "synaptic touchpad not recognized on dell latitude e6510 and others" [Undecided,Confirmed] https://launchpad.net/bugs/606238
[20:01] <sforshee> rik_, sure, go ahead and ask
[20:01] <rik_> sforshee: you ask for the output from input-events for further debugging. When I run that command it returns
[20:01] <rik_> protocol version mismatch (expected 65536, got 65537)
[20:01] <rik_> any idea on how to handle this?
[20:02] <rik_> Note that I'm running on debian testing with the 3.1 kernel
[20:02] <rik_> I've patched the psmouse module
[20:02] <sforshee> rik_, you need a newer version of input-events, or else modify the source yourself to remove that protocol version check
[20:02] <sforshee> iirc the check was simply removed when this problem surfaced
[20:04] <sforshee> rik_, http://www.kraxel.org/cgit/input/commit/?id=d99f056745e53cd2518ca169af474f8c45c1436d
[20:04] <sforshee> that's the patch to remove the check
[20:06] <rik_> sforshee: thanks, I've patched the code from trunk
[20:06] <rik_> when I look at xinput list it shows my touchpad as 12 (ps2 mouse) and 13
[20:06] <rik_> but when I run input-events, it shows for 12 HDA Intel PCH HP Out at Ext Righ
[20:06] <rik_> ?
[20:07] <rik_> and something similar for 12
[20:07] <rik_> 13
[20:07] <sforshee> rik_, the indexes from xinput aren't the same as input-events uses, use lsinput to get the argument you should pass to input-events
[20:08] <sforshee> rik_, also note that you need to run input-events from a virtual terminal to get the results. X will prevent you from seeing the events
[20:08] <rik_> sforshee: thanks for the hint. I ran it in X and it showed input for the ps2 device but not for the alps glidepoint
[20:08] <rik_> will try from a console
[20:10] <rik_> doesn't make a difference. only input from the ps2 device :-(
[20:11] <rik_> sforshee: would it make sense to play with the ALPS_PROTO version field in the driver?
[20:11] <sforshee> rik_, do you see REL_X and REL_Y events or ABS_X and ABS_Y?
[20:12] <rik_> REL_X
[20:13] <sforshee> rik_, then I think it's likely that you're still just getting PS/2 data
[20:13] <rik_> sforshee: I only get input on the PS2 mouse input device and nothing on the other device
[20:15] <rik_> what do the fourth and fifth field in the alps_model_info struct mean? for example 0xcf, 0xcf
[20:15] <sforshee> rik_, you could try changing the ALPS_PROTO field for v3 and v4 and see if it works
[20:16] <sforshee> rik_, the fourth and fifth fields are used for identifying proprietary-formatted data packets, if you're trying v3 or v4 they should both be 0x8f
[20:17] <rik_> V3 results in:  unknown response while entering command mode: 73 01 0d
[20:18] <rik_> what does the second field in the struct mean, for example 0x9b
[20:19] <rik_> V4 results in the same error message
[20:20] <sforshee> rik_, the second field is used to differentiate between different v3 and v4 models
[20:21] <rik_> sforshee: what are valid numbers to try there?
[20:21] <sforshee> rik_, based on those results I suspect yours isn't a v3 or v4 device. the response looks more like the response for an E7 report
[20:22] <sforshee> if you want to keep trying, you would need to change the second for your new model to 0x0d
[20:22] <sforshee> you also need to make alps_enter_command_mode recognize 0x73 and 0x01 as valid for the first two bytes of the response
[20:23] <sforshee> you can give it a try, but I don't expect it to work
[20:24] <rik_> sforshee: ok, will focus on V2 then. could PS2_INTERLEAVED make a difference in the events output?
[20:25] <sforshee> rik_, you might as well try v3 and v4 since it's fairly easy. but you may well be looking at another protocol that no one has deciphered yet.
[20:25] <rik_> sforshee: nice :-)
[20:25] <rik_> :-/
[20:26] <sforshee> rik_, do you or don't you have PS2_INTERLEAVED set currently?
[20:26] <rik_> currently set
[20:26] <rik_> but my v3 and v4 attempts did not have this set
[20:26] <rik_> they had ALPS_PASS set
[20:27] <sforshee> rik_, my guess is that if you remove it your results will get worse. But there's no harm in trying.
[20:27] <sforshee> it will be informative at any rate
[20:27] <rik_> so it should be set (ps2_interleaved) for all attempts (v2, v3...)
[20:27] <rik_> ?
[20:27] <sforshee> if your results get worse then it confirms my guess that the driver is just handling PS/2 data when you have it "working"
[20:28] <sforshee> no, don't set it for v3 and v4
[20:28] <sforshee> well, really it won't make any difference, the v3 and v4 support don't check that flag
[20:28] <rik_> if I change the alps_dump_packets int in the alps.c code to 1, will this give me more debug output
[20:29] <sforshee> possibly, but it will be a flood of data that probably isn't very useful at this point.
[20:30] <rik_> ok, will skip that then
[20:30] <rik_> the only way to really debug this is to follow your instructions on building a custom qemu?
[20:30] <sforshee> hrm, actually removing PS2_INTERLEAVED probably won't prove anything, there's another path for PS/2 data that's probably the one you're actually hitting
[20:31] <sforshee> and my statement about v3 and v4 ignoring the flag are incorrect now that I look at the driver again, it's in a code path common to all protocol versions
[20:31] <rik_> with V2 and ps2_interleaved enabled, the driver reports the following when loaded
[20:31] <rik_> E6 report: 00 00 64
[20:32] <rik_> E7 report: 73 03 50
[20:32] <sforshee> if you get to the point where the interleaved flag matters with v3 or v4 you're doing pretty good though :)
[20:32] <rik_> Status: 10 00 0a
[20:32] <rik_> sforshee: so it would make sense to try that? will do
[20:33] <rik_> no difference for v3
[20:34] <rik_> v4: nodifference
[20:35] <rik_> the DUALPOINT flag means that there's a touchpad and a stick between the keyboard keys?
[20:35] <rik_> or does it mean multitouch?
[20:35] <rik_> and what is a 4 direction button?
[20:35] <sforshee> rik_, it means a touchpad and a trackstick
[20:36] <rik_> my system is a dell inspiron 15R, and doesn't have a trackstick
[20:36] <sforshee> rik_, I don't have experience with the 4 direction button thing, but looks like it's for some hardware that has some extra buttons
[20:37] <rik_> I guess playing with those won't make a difference anyway?
[20:37] <sforshee> nope, i don't think you're getting far enough for them to matter
[20:38] <rik_> so the qemu method is the only way to get any further?
[20:39] <sforshee> rik_, I'd suggest adding a printout to alps_report_bare_ps2_packet to verify that you're still just seeing plain PS/2 data, if your message is printed it means that you are (which is my suspicion). If that's the case trying to sniff the Windows driver using qemu would be the next step.
[20:40] <rik_> your patch is for qemu or qemu-kvm?
[20:40] <sforshee> qemu-kvm
[20:41] <rik_> correct about the report_bare thing. it's spewing my log out :-)
[20:42] <rik_> will your patch work with 0.15.1?
[20:43] <sforshee> rik_, not sure, haven't tried it with 0.15.1
[20:44] <sforshee> if it applies cleanly there's a good chance it might work :)
[20:46] <rik_> seems to apply with some fuzzing
[20:50] <rik_> sforshee: it's building. I'll try the qemu thing when i find the time. Have to install windows inside the vm first. Thanks for your time
[20:50] <sforshee> rik_, np, let me know if you have more questions. Good luck!
[20:52] <rik_> sforshee: what timezone are you in?
[20:57] <sforshee> rik_, US central (UTC-6)
[20:59] <rik_> sforshee: so it's like 1pm for you?
[21:00] <sforshee> no, 3pm
[21:00] <rik_> ah yes
[21:00] <rik_> ok
[21:23] <jsalisbury> bjf, herton, possible regression between 3.0.0-12 and 3.0.0-13: bug 894292
[21:23] <ubot2> Launchpad bug 894292 in linux "Sandybridge suspend/resume regression on 3.0.0-12-generic/3.0.0-13-generic" [Medium,Triaged] https://launchpad.net/bugs/894292
[21:26] <herton> jsalisbury, we will check that
[21:27] <jsalisbury> herton, cool, thanks!
[21:48] <jsalisbury> ogasawara, Do you think this one should be on the hot list?  Installation failures for Precise VMs: bug 894768
[21:48] <ubot2> Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [High,Triaged] https://launchpad.net/bugs/894768
[21:49] <ogasawara> jsalisbury: sure.  probably needs more investigation though.
[21:50] <jsalisbury> ogasawara, thanks.  I'll request additional investigation to try and find a root cause.
[21:56]  * tgardner -> EOD
[22:09] <jibel> jsalisbury, is there any additional information I can provide? It's very easy to reproduce in our testing env and I can try to instrument the iso if it helps.
[22:10] <jsalisbury> jibel, Do you know if this only happens when installing Precise as a VM?  Have you see this in any of the physical machine installs?
[22:12] <jibel> jsalisbury, I've never seen it on a physical installation, only Precise VM. I'll try tomorrow on a physical machine.
[22:13] <jsalisbury> jibel, from the error, it looks like the install.py script is loosing access to a file handle and throwing I/O errors.
[22:14] <jsalisbury> jibel, are there any logs on the host that can be added to the bug?
[22:15] <jibel> jsalisbury, on my report it happens in write() but in duplicates it happens in close(), I've seen the same error with dpkg on an alternate amd64 install.
[22:16] <jibel> jsalisbury, I haven't found any useful information on the host, no disk or media error but I can attach logs from the host when that happens. Which one do you need ?
[22:17] <jsalisbury> jibel, hmm.  Maybe just the syslog and any logs specific to KVM.
[22:17] <jsalisbury> jibel, its interesting the error happens on a write() and close().  It's like it's loosing access to a file it had open.
[22:18] <jsalisbury> jibel, it would be good to see if it also happens with any other I/O operations in dup reports.
[22:18] <jibel> jsalisbury, this was the error with dpkg
[22:18] <jibel> Nov 24 10:01:11 in-target: dpkg: error processing /media/cdrom//pool/main/p/perl/perl-modules_5.14.2-5_all.deb (--unpack):
[22:18] <jibel> Nov 24 10:01:11 in-target:  failed in write on buffer copy for backend dpkg-deb during `./usr/share/perl/5.14.2/IO/Uncompress/Base.pm': Invalid argument
[22:19] <jibel> jsalisbury, I'll run the test again and will attach the host logs
[22:20] <jsalisbury> jibel, cool thanks.  I wonder if you could identify the file being written to when the error happens, and then see if you can get details on it.  Maybe it's getting corrupt?
[22:25] <jibel> jsalisbury, ubiquity doesn't report the file being copied. I'll see what I can do.
[22:26] <jsalisbury> jibel, hmm.  I haven't looked at the code yet, but do you think the file should have been copied somewhere, and it was not?
[22:27] <jibel> jsalisbury, I don't know
[22:28] <jsalisbury> jibel, ok, I'll take a closer look at the script tomorrow as well.
[22:29] <jibel> jsalisbury, great. thanks for your help
[22:29] <jsalisbury> jibel, np


[10:19] <abc33> Hi all How can I set Timos configuration in user-data?
[14:08] <holmanb> abc33: Welcome o/
[14:11] <holmanb> abc33: What is Timeos? I don't see any mention of it in a quick grep of the codebase, so I would imaging you're probably going to want to use runcmd/bootcmd if using builtin modules.
[17:22] <blackboxsw> falcojr: I think daily recipe builds broke on my recent changes for schema. https://launchpadlibrarian.net/603670335/buildlog_ubuntu-kinetic-amd64.cloud-init_22.2-3259-ga918e9e2-0ubuntu1+1968~trunk~ubuntu22.10.1_BUILDING.txt.gz
[17:22] <blackboxsw> falcojr: if you are not working it, I'll fix it. It's a unittest problem now that our versions schema doesn't use relative file paths
[18:39] <blackboxsw> https://github.com/canonical/cloud-init/pull/1486 put up for review for daily package build failures
[20:34] <mrf> Hi, im testing cloud-init for Ubuntu 22.04 LTS , the section "package: [fail2ban, unzip, htop]" didnt work. Checking official doc looks like its ok. Anyone got same issue?
[20:37] <blackboxsw> mrf: 'package:' is not a known key in the schema. https://cloudinit.readthedocs.io/en/latest/topics/modules.html#package-update-upgrade-install
[20:37] <blackboxsw> you need packages
[20:37] <blackboxsw> as you are missing an 's
[20:38] <blackboxsw> cloud-init schema is permissive and still allows for passing invalid/unknown keys as far as schema validation. Though we plan to tighten that to strict in the future to warn earlier about invalid/typo'd  schema
[20:38] <mrf> sorry misspelling typeing
[20:38] <blackboxsw> it happens to all of us
[20:39] <mrf> lets try again ... test 15 :P
[20:39] <blackboxsw> generally I'd like to be able to add a `--strict` parameter to `sudo cloud-init schema --annotate system` that would tell you about errors there in misspelled top-level keys. Any keys below a top-level key should have properly reported as an error in user-data though
[20:41] <mrf> thanks ! blackboxsw
[20:41] <blackboxsw> certainly
[21:01] <mrf> blackboxsw are u there? Im getting the same error : can you take a look? -> https://gyazo.com/77ed5468936d900b9447cc1f67a5aa68
[21:06] <blackboxsw> mrf looks like you are using the live-server installer from the logs you linked. I see exit code 100 in those logs. which generally (from APT) implies an APt error of sorts  such as APT lock being held by another process
[21:07] <blackboxsw> I wonder if something else is installing packages at the same time as curtin trying to install fail2ban package?
[21:07] <mrf> mmm
[21:08] <mrf> https://gyazo.com/c6102bcfe8d5d7e6f9f418d4beac300d
[21:08] <mrf> my cloud-init is quite simple i think so
[21:09] <blackboxsw> so, your clod-init contains "packages: [fail2ban...]" right? and the installer itself is also specifying a postinstall/install_fail2ban script?
[21:10] <blackboxsw> on the failed target machine, I'd like to see as much of `sudo cloud-init query userdata` as we can. Be wary if you have any passwords etc in that userdata
[21:12] <mrf> https://gyazo.com/849f571be39d08d8f74a3f9ebe011ba7
[21:12] <mrf> we just got a test password for this test
[21:13] <blackboxsw> mrf: good I was just going to warn you about the leak
[21:13] <mrf> yeah :=
[21:14] <blackboxsw> so cloud-init userdata you provided is installing the packages, and calling apt_update itself. So, I'm not sure why the subiquity installer environment is also trying to install_fail2ban too. It seems like this would be the exit 100 collision you are experiencing
[21:15] <blackboxsw> I'm looking through subiquity/live-server installer code now to see if I can grasp what is triggering that curtin-based system-install call
[21:16] <blackboxsw> mrf: looks like here https://github.com/canonical/subiquity/blob/main/subiquity/server/controllers/install.py#L227
[21:17] <blackboxsw> mrf: a shot in the dark, if you drop the `package_upgrade: true` from your userdata if you don't hit this problem
[21:18] <blackboxsw> if that is even possible given your install choices.  (I didn't catch whether you specified this userdata directly via autoinstall yaml or whether you manually went through the live-server installer dialogs
[21:18] <mrf> mmm let me check removing `package_upgrade: true`
[21:19] <mrf> we're trying develop a custom pxe server for our company
[21:19] <blackboxsw> +1 that makes sense mrf
[21:42] <mrf> im getting the same error
[21:43] <mrf> without `package_upgrade: true`
[21:49] <mrf> mm found this in the log : ERROR subiquity.common.geoip:119 geoip lookup failed
[21:51] <mrf> ok , im retard ... this airgapped network doesnt have acces to internet
[21:51] <mrf> then is unable to download all
[21:53] <blackboxsw> mrf: heh, it always comes down to the physical layer :) that'd do it, blocking unable to get access to the internet
[21:54] <mrf> :P  thanks for help blackboxsw
[21:55] <blackboxsw> glad we could debug a bit. I was worried about some timing collisions w/ live-installer invoking package installs at same time as cloud-init user-data being exec'd, but maybe not the case there.


[01:31] <Pici> wow, no one affected
[02:55] <Flannel> yay
[03:50] <Flannel> !separatehome
[03:56] <Flannel> What's different?
[04:01] <Flannel> well, besides the misspeling.
[04:01] <Flannel> oh, the irony.
[05:28] <maco> can ubot4 be updated so that i'm on the list of nicks it calls when !ops is used in #ubuntu-women?
[05:29] <maco> i dont know if i have perissions to do it, and if i do, i don't know how to do it
[06:19] <Flannel> Does ubot4 have a separate factoid DB? or do we just edit it with ubottu, and then they get mirrored?
[06:28] <tsimpson> it will sync from ubottu, but the ubottu here is not ubottu :)
[06:28] <Flannel> right, I heard about that earlier.
[06:28] <tsimpson> I could move it over now
[06:29] <tsimpson> in fact, I will
[07:15] <popey> Amaranth: you know you're opped in -ot?
[07:15] <Amaranth> oops, from this morning
[07:15] <Amaranth> wow
[08:40] <Gary> on it
[09:02] <elky> we need to figure out a better way to keep these bots synched
[09:08] <Myrtti> stupid bot
[09:08] <Tm_T> haha
[09:08] <Myrtti> *grunt*
[09:09] <Nafallo> lol
[09:17] <jussi01> elky: no, we need to finda better way to keep supybot from being shite and trashing the server
[09:17] <jussi01> the way we have works fine usually...
[09:34]  * Myrtti prods pici
[10:00] <elky> jussi01, that's great, but the same would happen if a backhoe hit a arterial fiber
[10:01] <elky> jussi01, i meant, a way to keep two databases in different geographical places synchronised
[10:05]  * popey has to google what a backhoe is
[10:11] <elky_> the thing your gas companies cut your telephone lines with.
[10:28] <popey> :)
[10:29] <popey> round here it's the thing the telephone companies cut the power lines with
[10:29] <elky_> same diff
[10:30] <elky_> my brother used to work for telstra, so i heard more about my version
[10:47] <ikonia> @login
[10:47] <ikonia> no, you're wrong
[10:48] <ikonia> @login
[10:48] <ikonia> is the bot borked ? I thought tsimpson had moved it back to the main db
[10:49] <Myrtti> it doesn't want to play nice on the pm either
[10:49] <ikonia> no, it's not responding to pm at all for me
[11:06] <elky_> stupid question, but is there a reason why we're letting fujisan in again?
[11:06] <Myrtti> where?!
[11:08] <elky_> -ot
[11:08] <elky_> he's acting almost normal though, i'll credit him that
[11:08] <Tm_T> elky_: but how long? (;)
[11:09] <elky_> Tm_T, a few days now
[11:14] <topyli> ikonia: i can't login either, at least from work
[11:15] <topyli> what will i *do* all day? :(
[11:21] <tsimpson> something's messed up...
[11:21] <Myrtti> DIE
[11:22] <Myrtti> THE BOT HATES ME
[11:28] <tsimpson> I'm getting to really dislike you ubottu
[11:31] <Gary> lol
[11:31] <tsimpson> somehow, the users database was just wrong
[11:35] <topyli> @login
[11:35] <tsimpson> give it a sec
[11:35] <tsimpson> it takes about 5 mins to fully sync
[11:35] <topyli> oh it just joined
[11:35] <tsimpson> yes, I said 5, because it sucks that badly
[11:36] <topyli> (:=
[11:36] <tsimpson> something bad happened to the users database...
[11:38] <tsimpson> @whoami
[11:38] <ubot2`> tsimpson: I don't recognize you.
[11:38] <tsimpson> jpds: ubot2` needs a new prefix please :)
[11:39] <tsimpson> topyli: /msg ubottu register topyli <some pass>
[11:40] <topyli> @login
[11:40] <topyli> \o/
[11:40] <topyli> @btlogin
[11:40] <tsimpson> ubottu: capability add topyli bantracker
[11:40] <tsimpson> ubottu: Admin capability add topyli bantracker
[11:40]  * Myrtti slaps ubottu
[11:41] <topyli> hehe
[11:41] <topyli> @btlogin
[11:41] <topyli> I GOT THE POWA
[11:41] <topyli> thanks tsimpson
[11:42] <bazhang> @login
[11:42] <tsimpson> no problem
[11:42] <bazhang> @btlogin
[11:42] <Myrtti> elky: did you see that on -ot?
[11:45] <Gary> Myrtti: Channel #ubuntu-au-vic is not registered.
[11:45] <Myrtti> I know
[11:48] <Myrtti> he's now on -irc
[12:16] <Myrtti> @bansearch recruit
[12:16] <Myrtti> I could *swear*...
[12:17] <Myrtti> ok, perhaps not
[12:56] <Pici> Myrtti: pong?
[13:40] <Myrtti> Pici: is it just me or is the bot broken?
[13:41] <Pici> Myrtti: Its not just you.  elky told me it was broken yesterday.
[13:41] <Pici> Unless its fixed now.
[13:42] <Pici> Myrtti: I think the databases that were connected were not the live ones for much of yesterday.
[13:42] <Pici> So bans, etc aren't there.
[13:42] <Myrtti> Pici: yes, but is the syntax I'm using to adding the factoids all wrong or is it just because the bot is borked?
[13:43] <Pici> Myrtti: Its right, maybe you werent logged in?
[13:47] <Myrtti> it just hates me
[13:47] <Pici> maybe :/
[13:54] <elky> we need proper data redundancy
[14:06]  * ikonia opens wallet
[14:15]  * Gary wants ikonia to buy an icecream for him
[14:15] <ikonia> ok
[14:15] <ikonia> I was thinking of some sort of redundency solution, but an ice cream is cheaper
[14:15] <Gary> yay
[14:24] <ikonia> !antiparty is for those of you who don't need to see the word !woot 300 times per minute, join here
[14:24] <ikonia> :)
[14:24] <Pici> :P
[14:37] <Pici> elky: How do you feel about changing the topic in -ot, we're getting quite o4o now.
[14:41] <elky> Pici, PFA coming out with that bull is annoying, since she's a self-confessed woman-hater.
[14:41] <ikonia> ?????
[14:41] <ikonia> am I missing something
[14:41] <Pici> ikonia: you missed -offtopic
[14:42] <ikonia> clearly
[14:42] <elky> ikonia, i got told i dont exist again.
[14:42] <ikonia> who said that ?
[14:42] <elky> thefunkbomb
[14:42] <ikonia> who's speaking ?
[14:42] <ikonia> did you hear something

[14:42] <elky> he's now realised that i do exist.
[14:42] <ikonia> never heard of "thefunkbomb"
[14:42] <elky> ikonia, nor had i until i no longer existed.
[14:43] <Pici> hell hath no fury, etc.
[14:43] <ikonia> oh, so a random
[14:43] <ikonia> ah
[14:43] <elky> ikonia, a misguided, yes.
[14:44] <Myrtti> elky: invisible pink unicorns
[14:44] <Myrtti> your excistance is a matter of faith
[15:05]  * genii runs out for a free McDonalds coffee
[15:30] <elky> i read that as gets the runs for free from mcdonalds coffee
[15:30] <elky> clearly bedtime.
[15:53] <Pici> !ghost
[15:54] <Pici> MenZa thinks we should replace /msg with /quote.
[15:55] <Pici> I said that /raw is used instead of /quote on some clients and that /msg is probably a better choice for compatiblity, objections?
[15:55] <Flannel> I think msg is the best lowest common denominator
[15:55] <Flannel> since yeah, some clients use raw
[15:56] <Flannel> which clients don't use msg?
[15:56] <Dave2> There's also no further security added with /quote nickserv on Hyperion, it just blindly /msgs it.
[16:09] <LjL> Dave2: it's a client thing though, using /msg will "generally" result in the client showing and/or logging the password
[16:10] <LjL> though then again, !register points to a document that uses /msg all the way...
[16:13] <Dave2> Sure, though many people store their passwords in their IRC client anyway.
[16:32] <popey> @btlogin
[16:32] <popey> jackjohnson a known fool?
[17:52] <DrolGodur> hi
[17:57] <genii> JackWat is getting pretty annoying in #u
[17:58] <genii> DrolGodur: Do you have some question or concern an op needs to assist with?
[17:59] <DrolGodur> i dont know if is a op needs but i would like to learn how to programming gui for ubunto ?
[17:59] <genii> DrolGodur: You are currently in #ubuntu-ops and nut a support channel.
[18:01] <genii> DrolGodur: When you try: /join #ubuntu does it bring you here?
[18:05] <DrolGodur> no i was loking for a channel with a programming guide for linux
[18:07] <genii> DrolGodur: Someone in #ubuntu channel will probably recomend something for you, Please do not idle in this channel.
[18:09] <DrolGodur> sorry
[18:22] <Seeker`> hi
[18:23]  * genii makes more coffee
[20:03] <Myrtti> hm
[20:03] <Myrtti> he was on ubuntu as<EMAIL_ADDRESS>[20:05] <genii> How do we check BT if ubottu is giving us invalid links?
[20:05] <Seeker`> @btlogin
[20:05] <Mez> @btlogin
[20:05] <Seeker`> @bansearch bolt_
[20:05] <Seeker`> @lgoin
[20:05] <Seeker`> @login
[20:05] <Seeker`> @bansearch bolt_
[20:05] <Mez> no dead links for me
[20:06] <Seeker`> @btlogin
[20:06] <ubot2`> Seeker`: You've given me 5 invalid commands within the last minute; I'm now ignoring you for 10 minutes.
[20:06] <Mez> HAHAHA
[20:06] <Seeker`> ubot2`: fine!
[20:06] <Seeker`> fscking bot
[20:06]  * Mez sticks fingers up at ubot2`
[20:06] <Seeker`> BT works for me
[20:06] <Myrtti> it does?
[20:07] <Seeker`> yarp
[20:07] <Myrtti> wohoo
[20:08] <Myrtti> !firewall
[20:08] <Myrtti> !!no firewall is <reply> Ubuntu, like any other linux  distribution, has firewall capabilities built-in. The firewall is managed using the 'ufw' command (see https://help.ubuntu.com/community/Uncomplicated_Firewall_ufw),  or 'iptables' (https://help.ubuntu.com/community/IptablesHowTo). GUI applications such as Firestarter/Gufw (Gnome) or Guarddog (KDE) also exist
[20:08] <Myrtti> THANK YOU
[20:10] <Myrtti> !ops-#ubuntu-women is <reply> BWEEP! Channel emergency! PriceChild, Nightrose, JanC, Aishiko, Gary, Susana, pleia2, LadyFrost, elkbuntu, Myrtti, hypa7ia, maco, nikkiana or Gareth!
[20:10] <pleia2> added Hobbsee last night
[20:11] <Myrtti> !ops-#ubuntu-women ~= /Susana/Susana, Hobbsee/
[20:11] <Myrtti> pleia2: was just about to add her
[20:11] <pleia2> thanks Myrtti :)
[20:12] <Seeker`> I always knew Gary was really a woman! :P
[20:17] <Myrtti> !ops-#ubuntu-women ~= /Gary/Gary, christel/
[20:17] <Myrtti> there we go
[20:19] <Pici> The ircc has access there too, but we probably have just ! o p s on hilight for all channels, I know I do.
[20:20] <Myrtti> I don't keep it on hilight just for the sake of my mental health
[20:29] <genii> I'm surprised Tm_T isn't on the #ubuntu-women list
[20:56] <Pici> @login
[21:05] <Seeker`> Saiki: how can we help you?
[21:07]  * genii makes more coffee
[21:46] <tsimpson> wth is up with the bot
[21:47] <tsimpson> make that, wth is up with ubottu.com
[21:48] <genii> Have you asked jussi01 ?
[21:48] <tsimpson> he's not here
[21:49]  * jpds would do something about ubot2 - don't have access to keys at the moment tho.
[21:50] <tsimpson> that's where hostmasks are a good thing :)
[21:56] <Seeker`> O.o
[21:57] <Seeker`> well the ubottu.com server is functioning, i'm on it right now
[21:57] <tsimpson> I can ping it, but I can't get a HTTP or ssh connection
[21:57] <ikonia> I'm on it via ssh
[21:57] <tsimpson> and ubottu (and my bot) were non-responsive
[21:58] <tsimpson> you're already connected, try making a new connection
[21:58] <ikonia> just did
[21:58] <ikonia> it's dns
[21:58] <ikonia> that's the problem
[21:59] <ikonia> oh wait
[21:59] <tsimpson> dns looks ok
[21:59] <ikonia> ubottu is not on the same server as as jussi01 any more
[21:59] <ikonia> my mistake
[21:59] <tsimpson> yeah, jussi01.com is fine, that's where ubottu is now
[21:59] <ikonia> sorry, being dumb
[22:00] <ikonia> I suspect it's under a brute force attack
[22:00]  * Seeker` can ssh to jussi01.com fine
[22:00] <ikonia> http and ssh are both listening but they can't respond
[22:01] <ikonia> thats the only common think I can think of that would allow them to both be listeing but not able to respond
[22:01] <ikonia> s/think/thing
[22:01] <tsimpson> Seeker`: I get no response from either
[22:01] <ikonia> nice and quick there ubottu
[22:01] <Seeker`> jussi01.com works fine. ubottu.com isn't accepting new connections for me
[22:02] <Seeker`> but I am on ubottu.com atm
[22:02] <ikonia> I can connect to ubottu.com - but the daemons can't respond
[22:02] <tsimpson> it's odd, isn't it
[22:02] <ikonia> Seeker`: look at the security log see if someone is bruting it
[22:03] <ikonia> for ssh and http to be both listening - still accepting connections, but unable to respond, thats the only situation I can think of that would cause that off the top of my head
[22:06] <Seeker> oi hai
[22:06] <Seeker> ssh connection just frozed
[22:06] <ikonia> yup
[22:07] <ikonia> brute brute brute
[22:07] <tsimpson> odd, HTTP connection sends the headers, but no data
[22:07] <ikonia> yup
[22:09]  * Seeker doesn't have permissions to access most of the log stuff on jussi01.com
[22:09]  * tsimpson can get you access
[22:09] <tsimpson> all you need is su and my password ;)
[22:10] <tsimpson> guess we'll just have to wait this one out
[22:12] <Seeker``> probably
[22:12] <Seeker``> can look at the logs if you want; not sure how much it will tell us
[22:14] <tsimpson> can you access the server now?
[22:15]  * jpds reckons we need a nagios check for the bots.
[22:17] <tsimpson> too much spam would be generated
[22:17] <jpds> Depends on the set up.
[22:18] <Seeker``> hmm
[22:18] <Seeker``> ubottu.com is still a total loss to me
[22:18] <Seeker``> fscking bot
[22:18] <tsimpson> I have ssh
[22:18] <Seeker``> jussi01.com is up and working for me
[22:19] <Seeker``> has ubottu.com been restarted?
[22:19] <Seeker``> my screen has disappeared
[22:19] <jpds> They're two separate hosts.
[22:19] <tsimpson> 00:19:35 up 2 min
[22:20]  * tsimpson starts playing with /etc/hosts.deny
[22:33] <Saiki> anyone here who can invite mt to the main channel?
[22:34] <tsimpson> you were just in #ubuntu
[22:34] <Saiki> 16:32 grisham.freenode.net 470:  | [0] Saiki, [1] #ubuntu, [2] #ubuntu-proxy-users, [3] Forwarding to another channel
[22:34] <Saiki> yea, but it keeps kicking me out :@
[22:34] <tsimpson> don't part #ubuntu-proxy-users
[22:35] <Saiki> I didn't
[22:35] <tsimpson> then it won't kick you out
[22:35] <Seeker`> @login
[22:35] <Seeker`> @btlogin
[22:35] <Seeker`> O.o
[22:35] <topyli> i'll contact him all right
[22:35] <topyli> :)
[22:35] <Saiki> tsimpson: it's cause I'm at the library, I don't think freenode/#ubuntu likes the network I'm on
[22:36] <Saiki> and I'm unable to join #ubuntu now
[22:37] <Saiki> I'm at the library near my house
[22:37] <tsimpson> try /cycle from #ubuntu-proxy-users
[22:37] <tsimpson> yes, Hammond Public Library
[22:37] <Saiki> aye
[22:38] <Saiki> 421:  | [0] Saiki, [1] cycle, [2] Unknown command
[22:38] <tsimpson> ok, just part and rejoin
[22:39] <Saiki> there we go
[22:39] <Saiki> any way to add an exception for this host/ip?
[22:40] <tsimpson> no, it's set per session
[22:40] <Saiki> ah..
[22:40] <tsimpson> we don't know who will use the connection after you, so an IP exempt would not be wise
[22:41] <tsimpson> now, back to that damn bot...
[22:41] <Saiki> I don't kno of anyone who uses irc here
[22:41] <Saiki> it's a royal pain in the ass to get ono irc as it is
[22:41] <Seeker`> ah, but you don't know everyone who may use that IP
[22:42] <Seeker`> you could well share a library with the worst troll in existence
[22:43] <Saiki> true enough
[22:43] <Saiki> but I highly doubt it, tbh
[22:43] <Seeker`> I dont :P
[22:44] <Saiki> lol
[22:45] <Saiki> considering how limited these pcs are, I do lol
[22:46] <Myrtti> was there anything else we can help you with?
[22:48] <Saiki> nope, sorry, just not parted yet
[22:48] <Saiki> thanks for the help in getting ito the chan
[22:54] <tsimpson> wow, just today ubottu.com has had breaking attempts from the US, China and Korea
[22:54] <tsimpson> huge dictionary attack from Korea
[22:56] <Seeker`> nice
[23:12] <Myrtti> fail2ban?
[23:12] <jdong> did the attempts have that big of an impact?
[23:14] <tsimpson> unless there was another issue going on that made ubottu.com stop responding to requests, yep
[23:15] <tsimpson> it's probably more likely that some moron knocked a RAID out of a stack somewhere, but whatever
[23:16] <Saiki> 17:15 sendak.freenode.net 404:  | [0] Saiki, [1] #ubuntu, [2] Cannot send to channel   <I'm getting this again :@
[23:16] <jpds> Yeah, you restarted your mibbit session/changed IP.
[23:16] <Myrtti> don't leave #ubuntu-proxy-users
[23:17] <jpds> ...or that.
[23:17] <Saiki> didn't do either, just changed my name
[23:17] <Saiki> I got disconnected from my network
[23:17] <Saiki> I hate how unstable it is :@
[23:20] <jpds> Hmm, Comcast.
[23:20] <tsimpson> Saiki: the exempt is on a complete hostmask, so changing nicks will invalidate it