[02:50] <xnox> @pilot in
[03:04] <YokoZar> slangasek: pitti: kees: infinity: stgraber: mdeslaur: congrats
[03:04] <YokoZar> lool: bdrung_: SpamapS: mterry: sorry :)
[03:04] <YokoZar> ^^^ Tech board election results
[03:06] <mdeslaur> YokoZar: thanks!
[03:06] <darkxst> xnox, could you take a look at gsettings-desktop-schemas and gnome-themes-standard during your shift?
[03:08] <xnox> darkxst: i don't usually do any DE/gnome/desktop things, unless i really know that it doesn't have negative effects across all flavours. Somebody more clued on those components would be better to review/merge those. E.g. Laney / seb128
[03:09] <xnox> darkxst: althought gsettings-desktop-schemas looks reasonable.
[03:18] <darkxst> xnox, gnome-themes-standard just has a handful of minor gtk fixes in the highcontrast theme (which all the other flavors use)
[03:20] <darkxst> and it fixes alot of theming issues in Adwaita
[03:20] <darkxst> but anyway will check with Laney or seb128
[03:21] <xnox> darkxst: looking into gnome-themes-standard, i wonder what the lock screen changes are. (background keys?!)
[03:25] <darkxst> xnox, not sure what changes you mean, however the lock screen is gnome-shell only
[03:27] <xnox> darkxst: right. will test the package more and then upload.
[03:27] <darkxst> thanks
[04:39] <xnox> @pilot out
[04:39] <xnox> @pilot out
[04:58] <Apteryx> Hi there. Could someone tell me what is the general user case of the bluetooth applet operation?
[05:00] <Apteryx> If I turn bluetooth off from the applet, the icon disappears and the interface goes down. Good. "service bluetooth status" reports that it is still running.
[05:00] <Apteryx> Now what I am suppose to do to bring it back ON?
[05:01] <Apteryx> I guess the designed way is to go to "Settings -> Bluetooth" and there turn the swith ON.
[05:01] <Apteryx> The switch turns ON, but the interface stays down in my case, as reported by hciconfig.
[05:02] <Apteryx> Is this hardware specific? My bluetooth interface is provided by the Atheros AR3011 chip.
[05:46] <SpamapS> YokoZar: hah, thanks for the consolation. Though I'm not on the TB, I think the results came out _wonderfully_. :)
[05:46] <SpamapS> Truth be told I'm a bit relieved. It is a big responsibility.
[05:47] <YokoZar> SpamapS: If you want to stage a coup, let me know.
[06:14] <slangasek> YokoZar: thanks!  is there any more official announcement of this? :)
[06:15] <YokoZar> slangasek: Usually pleia2 puts out something on the Fridge and such, I imagine she'll do that tomorrow after the CC meeting
[06:15] <slangasek> ok
[06:34] <stgraber> YokoZar: thanks!
[07:16] <darkxst> Logan_, was there some reason why you disabled JS support in mediatomb?
[12:54] <caribou> xnox: you have marked the merge of backuppc as "please take"
[12:55] <caribou> xnox: I'd like to get some more merge experience, could it be a good idea for me to work on this one ,
[12:55] <caribou> ?
[12:57] <xnox> caribou: sure, although Logan_ was the last one to merge it "properly". I'll certainly can review your work for correctness.
[12:57] <caribou> xnox: I'll check with Logan_ first, in case he's started to work on it
[13:29] <caribou> xnox: how about the php5 one ?
[13:29] <caribou> xnox: looking at it, mostly done
[13:30] <xnox> caribou: it's non-trivial. I giving up some of the merges, because i don't feel comfortable merging them.
[13:31] <caribou> xnox: ah, ok I see
[13:31] <xnox> caribou: if you are looking into something to do really good things (and easy) to fix are http://qa.ubuntuwire.com/ftbfs/ppc64el.html and http://qa.ubuntuwire.com/ftbfs/arm64.html
[13:31] <xnox> caribou: typically it needs enabling dh-autoreconf (and sometimes dh-autotools-dev), such that config.guess/.sub and libtoolize are updated during builds.
[13:32] <caribou> xnox: ok, I'll look at it
[13:34] <caribou> xnox: is there an "easy" way to test those builds locally (i.e. w/o having some ARM H/W) ? Can sbuild do that ?
[13:37] <rbasak> caribou: https://www.stgraber.org/2012/02/03/ever-wanted-an-armel-or-armhf-container-on-an-x86-machine-its-now-possible-with-lxc-in-ubuntu-precise/ might work for you
[13:37] <caribou> rbasak: thanks, will try that
[13:37] <rbasak> I've never tried it with sbuild though :)
[13:37] <rbasak> However, for sbuild, it might be possible to just use qemu-user-static actually.
[13:37] <xnox> caribou: well, those fixes are needed on arm64/ppc64el for which emulators might not be stable (or exist) or be slow.
[13:38] <rbasak> I imagine you can set up a chroot with qemu-user-static installed, and then everything should just work. But I'm not sure if mk-sbuild can do that for youj.
[13:39] <xnox> caribou: in practice, it trains trianging the type of build failure and fixing it. E.g. if configure says that it can't determine system machine time, then config.guess/.sub need updating (preffered with dh-autoreconf, dh-autootools-dev if doesn't work)
[13:39] <rbasak> Not sure of qemu status with ppc64el. AFAIK qemu-user-static for powerpc is pretty broken.
[13:39] <xnox> caribou: and check locally that during build, config.guess timestamps are updated =) and all of them.
[13:39] <xnox> caribou: and e.g. grep for the arm64/ppc64el gnu triplets in the update config.guess/.sub.
[13:41] <xnox> caribou: for ppc64el, one often needs dh-autoreconf to update libtool, as otherwise the build log will have "libtool supports shared libraries... no" or some such and weird build error at the end with "dh_install can't find *.so" or static linking of some binaries fails.... because well it wasn't detected correctly that shared linking is available and is the only one support.
[13:42] <caribou> xnox: still, as for ftbs on amd64/i386 I need to be able to test the build locally
[13:42] <caribou> xnox: I've done a few of those already, but never on arch other than amd64/i386
[13:56] <xnox> caribou: sure, but the links i gave you, most of the packages do build correctly on i386/amd64/armh/powerpc. It's just the new ports that need enablement.
[13:57] <xnox> caribou: and it's better to have a FTBFS with a real arch-specific bug, instead of the "config.guess is out of date, abort"
[13:58] <caribou> xnox: true, but I still need to be able to test the build to find out, isn't it ?
[13:58] <caribou> xnox: at least test the fix
[14:01] <xnox> caribou: well sure, you need to make sure that the package still builds after autoreconf is enabled, and verify that config.guess/sub is updated, and libtoolize is executed (if applicable)
[15:26] <sconklin> @pilot in
[15:41] <shadeslayer> is there any news on a bluez5 migration?
[15:49] <infinity> shadeslayer: Which news were you hoping for?
[15:51] <shadeslayer> Any blueprints or any ongoing work to package Bluez5?
[15:51] <infinity> It's been packaged in Debian experimental, though no activity there since May.
[15:51] <infinity> No idea if anyone's dicussed and/or committed to doing the work in Ubuntu.
[15:52] <shadeslayer> well, on the KDE side, the powerdevil 1.x series will be EOL soon
[15:52] <shadeslayer> and only the 2.x series will be supported
[15:52] <shadeslayer> which in turn depends on Bluez5
[15:53] <infinity> Sure.  I suspect some effort needs to be put in to testing (and possibly porting) all the rdeps.
[15:56] <mitya57> doko: What should be done in qtchooser re bug 1209239?
[15:57] <shadeslayer> infinity: only 46 reverse deps ... right :D
[15:57] <caribou> following my previous discussion with xnox, does someone have a suggestion on how to setup an environment to test builds on arm64/ppc64el ?
[15:58] <infinity> caribou: For arm64, you could try https://wiki.debian.org/Arm64Qemu
[15:59] <infinity> caribou: But most of the bugs people need to fix (config.{sub,guess} updates and libtool macro updates) can be easily tested for correctness on any arch.
[15:59] <xnox> mitya57: that's rather for me, rather than doko. qtchooser demands & searching for native arch qt installation, instead of guessing / using native tools without a full native qt installation.
[16:00] <infinity> caribou: Sure, the build *might* fail later for other unrelated reasons, but history has shown that's only likely in about 1/100 such uploads.
[16:00] <xnox> mitya57: e.g. the dreaded "can't find qt installation" should be resolved, such that it always finds native qt-tools, even though native qtbase-dev is not installed.
[16:00] <caribou> infinity: ok, thanks I'll look at that
[16:00] <caribou> infinity: I already found apw's blog post on using ARM64 Foundation mode
[16:01] <infinity> caribou: The Foundation Model is certainly going to give you the most correct results.  But it's sloooooow.
[16:01] <caribou> infinity: yeah, I noticed that already
[16:02] <infinity> caribou: But, honestly, for most of these uploads, you shouldn't need to build on the tagret hardware to know that what you're fixing is correct.
[16:02] <infinity> caribou: If you do need to build on target hardware to see the fix in action, there's a fair chance you don't understand the fix.
[16:02] <caribou> infinity: that could happen as well ;-)
[16:02] <infinity> (Again, discounting the 1% of the time when things need actual porting)
[16:03] <caribou> infinity: but then, if the FTBS is not arch specific, it should fail on the other arm builds as well
[16:04] <rbasak> I've never felt confident uploading without doing at least a build test to check a fix. It's a way of checking my own work.
[16:04] <infinity> rbasak: I always build-test on *some* arch. :)
[16:05] <mitya57> xnox: Right, thanks. I think opening a bug upstream makes sense.
[16:05] <rbasak> If it's an arch-specific issue, I check two arches.
[16:05] <infinity> But for autotools type updates, I'm happy to build-test on x86, and spot-check that the update machinery did what I wanted.
[16:05] <mitya57> (does qtchooser have a bugtracker???)
[16:05] <rbasak> I guess I'm not confident enough with autotools for that.
[16:06] <infinity> rbasak: Well, that goes back to "understanding the fix". :)
[16:06] <rbasak> I think there's a difference between thinking I understand the fix, and knowing that I understand the fix.
[16:06] <infinity> rbasak: If you're not confident with the autogenerated code, I'm not sure how "it accidentally worked on two arches" is any better than "it accidentally worked on one".
[16:08] <caribou> infinity: rbasak: which goes back to my assertion that if it's not arch specific, it should ftbs on more than one arch build
[16:08] <xnox> mitya57: yeah, i was going to get to that soon. But am busy with touch-emulator work at the moment.
[16:08] <infinity> caribou: Sure, but you're trying to fix arch-specific issues here.
[16:09] <caribou> infinity: simply because xnox pointed be to a bunch of ftbs on amd64 qa page
[16:09] <caribou> s/be/me
[16:10] <xnox> caribou: well i pointed to both ppc64el, arm64. And I has _explicit_ that you do _not_ need to test build on arm64/ppc64el.
[16:10] <infinity> Not for autotools mangling, anyway.
[16:10] <infinity> Not if, like I said, you understand the fix and how to spot-check that it's correct.
[16:10] <caribou> xnox: yeah, I got that as well, but then when I looked at some failures, they did not relate to what you described
[16:10] <caribou> xnox: so I got further in the arm64 specific builds
[16:10] <xnox> caribou: note, that a test build on amd64 is sufficient as long as you verify that: you are fixing config.guess/libtool issues, and that package does update config.guess/libtoolize correctly during any build (e.g. amd64 is sufficent)
[16:11] <xnox> caribou: step one was to find those that are that issue =) most of them are in the universe section ;-)
[16:11] <infinity> caribou: There are, of course, a hundred or so failures on x86 too, you could look at those. :P
[16:11] <xnox> caribou: main is mostly fixed now.
[16:11] <caribou> infinity: that's what I did last week :)
[16:11] <xnox> caribou: and there is more chance on the ppc64el page ;-)
[16:12] <caribou> xnox: infinity: bottom line is : many of those are good ground for me to learn tons of things
[17:10] <rbasak> xnox, mdeslaur: FYI, I'm planning on merging apache2 and php5 this week.
[17:10] <rbasak> Any objections?
[17:14] <xnox> rbasak: yes please. =) you know how to test all of that stuff properly.
[17:16] <rbasak> xnox: indeed. I run the dep8 tests I wrote :-P
[17:17] <rbasak> I think there are a bunch of bugs that can be trivially fixed with a merge, too, which I'll sort out at the same time.
[18:07] <mdeslaur> rbasak: no objections from me!
[18:07] <mdeslaur> :)
[18:15] <xnox> rbasak: omg, you have Technical Board member blessing for that work. You are totally invincible now ;-)
[18:23] <mitya57> Can anybody please upload a python-apt rebuild (for python3.4)?
[18:24] <mitya57> (Builds fine in a PPA)
[19:22] <Laney> tkamppeter: your poppler uploads broke ABI
[19:22] <Laney> xpdf is busted now
[19:22] <Laney> & evince
[19:23] <tkamppeter> Laney, in which point did they break ABI, perhaps I can get fixed patches.
[19:23] <Laney> ubuntu5 it seems
[19:23] <Laney> PSOutputDev::PSOutputDev(char const*, PDFDoc*, char*, int, int, PSOutMode, int, int, bool, bool, int, int, int, int, bool, bool, GooString* (*)(PSOutputDev*, PSOutCustomCodeLocation, int, void*), void*)
[19:24] <infinity> Quite, yes.
[19:24] <infinity> tkamppeter: As a general rule, a patch that changes a function prototype is going to break ABI...
[19:24] <infinity> Were these backports from a new upstream version?
[19:25] <infinity> Perhaps we just want the new upstream and an SOVER/ABI transition.
[19:25] <tkamppeter> Laney, I will ask upstream whether one can do it without breaking ABI. The patches are from upstream. It is https://bugs.freedesktop.org/show_bug.cgi?id=72312.
[19:26] <infinity> Note that if you back out the ABI breakage, you'll also have to rebuild anything that build agaist the library post-breakage.
[19:27] <infinity> If we don't plan to take a new poppler soon, you should really just back out those patches *now* before the ABI break leaks any further.
[19:27] <infinity> And then sort out how to fix it differently.
[19:28] <infinity> tkamppeter: ^
[19:28] <Laney> The changes aren't even committed upstream yet
[19:28] <Laney> AFAICS
[19:29] <infinity> Yeah, then definitely please back them out.
[19:30] <infinity> And then hunt for rdeps that were built against the new ABI, so we can rebuild them.
[19:31] <tkamppeter> Laney, infinity, I have informed upstream now asking them to find a solution without ABI change. I will step back to the state before these upstream changes.
[19:31] <infinity> tkamppeter: For upstream, an ABI break is fine.  They break ABI in poppler constantly.
[19:31] <infinity> tkamppeter: But we *can't* backport that to our current package, that's all.
[19:32] <infinity> Oh crap.
[19:33] <infinity> Everything that depends on poppler in ppc64el is probably broken.
[19:33] <infinity> Oh, I guess it's not that many things anyway.
[19:34] <infinity> But yeah, we might have to rebuild all of poppler's rdeps after you fix it, just to be on the safe side.
[19:34] <infinity> I'll look at that more closely when I get back from lunch.
[19:50] <mitya57> We may want poppler 0.24.5 or 0.25 (both have different abis from 0.24.4)
[19:50] <mitya57> There is a bug somewhere with my debdiff for 0.24.4->0.24.5 attached
[19:58] <Laney> you mean .3 -> .4 I guess
[19:59] <mitya57> Err, yes, of course
[19:59]  * mitya57 puts the time machine back
[20:01] <mitya57> And, actually, the tkamppeter's change and .3->.4 changes are unrelated :(
[20:03] <Laney> yeah, that's what we observed just now
[20:04] <Laney> Maybe they could be cherry-picked to the 0.24 series once committed to 0.25 for .5 which we could take, or something.
[20:05]  * mitya57 needs some sleep, will be able to help with poppler tomorrow
[20:06] <mitya57> (I am also in process of forwarding our changes to Debian)
[21:25] <tkamppeter> infinity, Laney, I have now uploaded poppler -0ubuntu12, reverting to my patches which I have created to fix the bugs and proposed upstream. They do not have any ABI changes.
[22:04] <infinity> doko: Bah, syncing Debian's differently multi-arched tk/tcl broke upgrades.
[22:06] <doko> infinity, in which way?
[22:07] <infinity> doko: 8.6 needs the same fix you applied to 8.5
[22:08] <doko> ahh, you mean the replaces for tcl-lib?
[22:08] <infinity> doko: I'll do it right now, unless you want to be TIL on tcl/tk
[22:08] <infinity> doko: Yeah.
[22:08] <doko> no, please go ahead
[22:08] <doko> looking at the ruby2.0 ftbfs now ...
[22:47] <doko> https://launchpadlibrarian.net/161446482/buildlog_ubuntu-trusty-amd64.ruby2.0_<IP_ADDRESS>3-1build1_FAILEDTOBUILD.txt.gz
[22:47] <doko> infinity, ^^^ tries to link -lieee twice, and then complaining about a duplicate symbol from the same library?
[22:51] <infinity> doko: Works on ARM and PPC, time to ditch x86 from the archive.
[22:53] <doko> infinity, fails on armhf too, looks like glibc complains
[22:54] <doko> ahh, no, it's the test_gc testcase
[22:54] <infinity> doko: Why is it linking that statically at all?
[22:55] <infinity> doko: The previous build seems to be linking -ltk8.5
[22:57] <infinity> doko: Did the library shuffling lose the .so -dev symlink for tcl/tk?
[22:58] <doko> infinity, enoclue yet, it has -DSTATIC_BUILD on the command line
[22:58]  * infinity looks closer.
[23:01] <infinity> lrwxrwxrwx 1 root root      11 Jan  1 23:28 /usr/lib/x86_64-linux-gnu/libtk.so -> libtk8.6.so
[23:01] <infinity> -rw-r--r-- 1 root root 1392528 Jan  1 15:41 /usr/lib/x86_64-linux-gnu/libtk8.6.so
[23:01] <infinity> lrwxrwxrwx 1 root root      11 Jan  1 15:41 /usr/lib/x86_64-linux-gnu/libtk8.6.so.0 -> libtk8.6.so
[23:01] <infinity> Well, that's backwards... But should still work.
[23:02] <doko> still has the /usr/lib/x86_64-linux-gnu/libtcl.so symlink
[23:03] <doko> and it build ok locally
[23:05] <doko> but doesn't link with -lieee locally
[23:07] <infinity> It builds fine locally?
[23:07] <infinity> With current tk-dev?
[23:07] <doko> yes. rechecking on osageorange
[23:08] <infinity> So, -lieee is from tkConfig.sh *but*, it was there in 8.5 too.
[23:08] <infinity> And I suspect only shows up on static builds.
[23:08] <infinity> So, my guess is that your local build didn't do the static thing, for whatever reason.
[23:09] <sconklin> @pilot out
[23:21] <infinity> doko: Fails locally here.  I wonder what you've done to make your computer like it.


[20:08] <damasceno> How much should i charge for the LTSP Server that i'll make for a client?
[20:10] <damasceno> Somebody?
[20:15] <Linden940> as much as you want
[20:16] <Linden940> its a free software...your not selling the software...your selling the time it TOOK you to set it up and ect
[20:16] <damasceno> Linden940, i know that.
[20:16] <Linden940> most programmers charge around 30 to 40 an hr give or take
[20:16] <damasceno> Really?
[20:16] <Linden940> so take that X amount of time and you'll get your price
[20:17] <Linden940> you need a program to be modded for what ever reason your company needs it for
[20:17] <damasceno> Oh, i was thinking in charge $ 1.500
[20:17] <Linden940> i have seen prices from $25 as much as $300 an hour
[20:17] <damasceno> hum.
[20:18] <Linden940> but there is something called "beating a dead horse"
[20:18] <Linden940> so dont beat someone to death and rob them of all there money...
[20:18] <Linden940> you do them right...they will more than come back to you over an over :)
[20:18]  * Linden940 talking from exp
[20:19] <damasceno> Linden940,  hum...
[20:20] <damasceno> In this case, i'm the company called Oficina Livre.
[20:20] <damasceno> And We will take this service.
[20:20] <Linden940> i own a company called Easy Recycle
[20:21] <damasceno> If i was doing the service, i charge 50 per hour.
[20:21] <Linden940> as noted before...dont kill them for all there money
[20:21] <Linden940> $50 is very low price per that is out there
[20:21] <Linden940> low price = more work
[20:21] <damasceno> But, in this case, is the company, so, i think the better price, will be $ 200 per hour.
[20:21] <damasceno> Linden940, understood.
[20:21] <damasceno> Thank you man. :D
[20:22] <coz_> damasceno,  all set now? :)
[20:26] <damasceno> coz_, Yep, thank you too.
[20:26] <damasceno> :D
[20:26] <coz_> very cool
[20:28] <damasceno> I will see that now, cause i'll install a red5 server.
[20:28] <damasceno> The client is from E.U.A
[20:28] <damasceno> I'm from Brazil. :)
[20:28] <damasceno> I hope you don't notice that... my english is very bad.
[20:28] <damasceno> lol
[20:29] <Linden940> its not that bad
[20:29] <Linden940> i have seen worse
[20:29] <Linden940> lol your very understandable
[20:30] <damasceno> But, english is easy if you study...
[20:30] <damasceno> Portuguese no :/
[20:30] <Linden940> lol
[20:31] <Linden940> well english is pretty easy...or so i think
[20:31] <damasceno> Por exemplo, em português eu falo dessa maneira.
[20:31] <Linden940> but its all so pretty much the ONLY lag used with computers/programming
[20:31] <damasceno> Translate: For example, in portuguese i talk that way.
[20:32] <damasceno> lol
[20:32] <damasceno> lol = funny, right?
[20:32] <Linden940> would of had it (got the translator out an ready)
[20:32] <damasceno> In portuguese, we laugh like this:
[20:32] <damasceno> hehehe, kkkkkkkkkkkk...
[20:33] <Linden940> lol i c
[20:33] <damasceno> Linden940, where you from?
[20:34] <Linden940> world-usa-tx-dallas
[20:34] <damasceno> Cool.
[20:34] <Linden940> hmm most times...very hot
[20:34] <Linden940> but yea it is starting to get very cool here
[20:35] <damasceno> :)
[20:35] <damasceno> I wanna know the Silicon valley.
[20:36] <Linden940> have not been there as of yet
[20:36] <damasceno> Is right name of the "City of technology"?
[20:37] <damasceno> I saw the city on the poster...
[20:37] <Linden940> yea it is
[20:37] <damasceno> Google, Dell, everything is in there
[20:37] <Linden940> youtube is there as well
[20:37] <damasceno> =)
[20:38] <Linden940> well me afk
[20:38] <damasceno> But, i'm still young, i wanna go to there with 25 years...
[20:39] <damasceno> Linden940, ok, thank you again.
[20:39] <damasceno> i'll work, cya.


[02:16] <johanbr> According to the topic, the latest kernel upload seems to have been in progress for about a month now. :)
[02:16] <pwnguin> seems true
[02:17] <pwnguin> at the moment, the package "linux" holds the 2.6.24 kernel
[02:17] <pwnguin> but im missing a few restricted drivers and iwl
[02:17] <johanbr> It does? My mirror doesn't have a 2.6.24 kernel at least.
[02:18] <pwnguin> in hardy?
[02:18] <pwnguin> apt-cache show linux
[02:18] <pwnguin> oh
[02:18] <johanbr> Right. No 2.6.24 kernel.
[02:18] <pwnguin> good point
[02:19] <pwnguin> apt-cache show 2.6.24 does show up though
[02:21] <johanbr> Oh, never mind.  Found it.
[02:21] <pwnguin> but i dont think its finished uploading / building / something
[02:22] <johanbr> No, it's done: https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-1.1
[02:27] <pwnguin> hmm. well i guess once im done updating, i'll go back and see why wireless isnt working
[06:00] <imbrandon> BenC: ping, how much trubble ( or what do you need from me to make is easier/faster ) to get "omfs-source" from the archives into l-u-m
[08:22] <kraut> moin
[08:41] <Kano> hi pkl_
[08:42] <Kano> could someone tell me how to check for the kernelversion used in a rules.modules file?
[08:44] <Kano> i have got KVER in there as var...
[10:17] <Kano> ok, found a solution for that, but that only fixes things for 2.6.23 (avm drivers)
[10:41] <gaspa> there's someone with slub/slab experience? i want to understand when to use the first, when the latter...
[10:57] <andres> gaspa: Except for bugs in slab I dont think there are many valid reasons using slab.
[10:58] <andres> Replace first slab with slub.
[10:58] <gaspa> andres: there are no cases in which slab if more efficient?
[11:00] <andres> Maybe there are some, but not out of architectural reasons.
[11:02] <andres> And be aware that there were some bugs making slub way much slower in 24-rc? releases.
[13:44] <pitti> BenC: so, maybe I'm confused
[13:44] <pitti> But https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/57233/comments/12
[13:44] <ubotu> Launchpad bug 57233 in linux-source-2.6.15 "Minor revision 2.6.15-26 doesn't detect attached SCSI disks to LSI 1030ST" [High,In progress]
[13:44] <pitti> seems to indicate that this bit was a regression:
[13:44] <pitti> linux-source-2.6.15 (2.6.15-51.63) dapper-proposed; urgency=low
[13:44] <pitti>  * megaraid: Move AMI/Megaraid3 IDs from megaraid_mbox.ko to megaraid.ko
[13:44] <pitti>  * megaraid: Move AMI/Megaraid3 IDs from megaraid_mbox.ko to megaraid.ko
[13:44] <pitti>     - LP: #57233
[13:44] <pitti> (oops, sorry for the double line)
[13:45] <pitti> BenC: ah, so you do plan to back out that change to get back to the current dapper-security behaviour, and fix the bug in lbm instead?
[13:45] <BenC> pitti: right
[13:45] <pitti> ok, then I just misunderstood you
[13:46] <pitti> BenC: ok, so the backing out of this bit should be easy and do little harm, right?
[13:46] <BenC> pitti: right, now we're on track :)
[13:47] <pitti> let's hope that Vide tests the new lbm then
[13:48] <pitti> BenC: but unless you have some other showstoppers, shall we get this uploaded and new CDs built for testing?
[13:48] <BenC> pitti: I think that's a good idea, ppl can test in the meantime
[13:49] <BenC> pitti: I'll get the uploads done once I've had a cup of coffee
[13:49] <pitti> BenC: enjoy, and thanks
[15:47] <BenC> pitti: lbm-2.6.15 is in dapper-proposed awaiting approval
[15:50] <pitti> BenC: nudged, thanks
[16:17] <BenC> pitti: I'm checking if this megaraid change breaks ABI, after that I'll upload
[16:17] <pitti> BenC: *crossing fingers that it won't* :)
[17:14] <BenC> pitti: good news, no change in ABI
[17:14] <pitti> phew
[17:54] <pitti> BenC: so, dapper.2 meeting in 5?
[17:54] <BenC> pitti: yeah
[20:01] <pitti> BenC: ah, I know why I didn't notice the mpt symbol error in my existing dapper install
[20:01] <pitti> BenC: in d-i, it prefers the driver from lbm, but in an installed system it prefers the one from linux-image
[20:02] <pitti> BenC: at least I get 3.03.04 loaded
[20:05] <pitti> BenC: that's both in my permanent dapper vmware as well as the one I just test-installed
[20:07] <pitti> BenC: modules.dep does not have any "/updates/" in it; after a depmod -a it has
[20:13] <pitti> BenC: might the reason be that the one in /updates had the faulty symbols?
[20:14] <BenC> pitti: make sure depmod -a is run, and update-initramfs -u afterwards
[20:16] <pitti> BenC: right, after depmod -a I get the new version
[20:16] <pitti> BenC: my concern is, if in a fresh install the old version is used, then that sounds like a bug?
[20:16] <pitti> (i. e. the default modules.dep is wrong)
[20:17] <BenC> pitti: lbm should be running depmod, and update-initramfs, at least it did on my system
[20:17]  * pitti upgrades to the new lbm in -proposed and tests further
[20:23] <maks_> BenC: initramfs-tools in unstable has pretty stabilized
[20:23] <maks_> so if you wana go for long term support a merge would be cool
[20:23] <maks_> can lend my eyes to the resulting diff
[20:23] <maks_> :)
[20:24] <pitti> BenC: ah, after upgrading to new lbm I get 3.03.09 by default on boot, so that looks good
[20:24] <pitti> BenC: I'll test it again tomorrow when it's on the CD (the modules.dep issue)
[20:38] <pitti> BenC: hmm: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/56885/comments/6 :(
[20:38] <ubotu> Launchpad bug 56885 in linux-source-2.6.15 "e1000 driver not working properly on x86_64?" [Medium,Fix committed]


[04:57]  * Hobbsee beats the compiz devs with a big stick
[04:58] <Hobbsee> i would appreciate it if the latest changes didn't cause all my apps to freeze!
[05:19] <manchicken> Hobbsee: Howdy.
[05:21] <Hobbsee> heya manchicken!
[05:53] <manchicken> Hobbsee: How goes?
[05:53] <Hobbsee> manchicken: well, i moved to the dark side fully yesterday, which was fun.
[05:53] <manchicken> Which dark side?
[05:54] <Hobbsee> the one without kde in it
[05:54] <manchicken> The GNOME side?
[05:54] <Hobbsee> yeah
[05:54] <manchicken> I'm digging the GNOME side.
[05:54] <Hobbsee> oh, hmm, i'm using mvo's compiz now, aren't i?
[05:55] <manchicken> I love the KDE community... but I dig the standardized Ubuntu GNOME.
[05:55] <Hobbsee> and how options are all in the same place?  yeah
[05:55] <Hobbsee> still gets me between an ubuntu and a windows firefox, though
[05:59] <manchicken> I haven't used windows in more than 2 years.
[06:00] <manchicken> I've had my in-laws try to get me to help them with their windows boxes, I don't even bother anymore.
[06:02]  * ajmitch wonders what's so dark abotu this side
[06:03] <Hobbsee> manchicken: i think the uni'd kill me if i suddenly started switching the workstations to ubuntu there
[06:03] <manchicken> heh
[06:04] <manchicken> ajmitch: Novell :)
[06:04] <ajmitch> what about them?
[06:04] <manchicken> You asked what's so dark, Novell is :)
[06:04]  * manchicken trolls lightly.
[06:20] <dholbach> good morning
[09:22] <seb128> hey mvo
[09:23] <mvo> hey seb128!
[09:23] <seb128> mvo: so they fixed your dsl yesterday? ;-)
[09:23] <mvo> seb128: yeah, came back (by magic) ~3h later
[09:24] <mvo> seb128: today a technican was at my place to check everything but he said all was fine (and claimed nothing was wrong on their side)
[09:24] <mvo> I will keep a eye on it
[09:25] <seb128> they always claim nothing is wrong on their side
[09:39] <doug2266778822>  im running ubuntu gutsy gnome and i can not get my head phoen jack to work. can anyone help me?
[09:41] <seb128> doug2266778822: try #ubuntu for user questions
[09:41] <doug2266778822> seb128:  i have asked for the last hour no one seems to wanting to help me
[09:42] <seb128> doug2266778822: try http://answers.launchpad.net/ubuntu then maybe, this channel is one for user questions
[10:42] <crevette> hey ubuntu's looking for an GNOME Maintainer
[10:45] <pitti> crevette: you happen to know one by any chance? :-P
[10:46] <crevette> there are good at least here
[10:46]  * crevette should stop opening dup bugs
[10:49] <crevette> pitti, I'm sure a lot of people are interested with, but unfortunately I don't know one personnaly
[10:49] <crevette> s/are/is/
[10:53] <Hobbsee> crevette: don't be fooled, tehy just want to run them into the ground.
[10:53] <Hobbsee> what happens to seb128, then?  or do they comaintain?
[10:53] <crevette> Hobbsee, :)
[10:54] <seb128> Hobbsee: want to comaintain GNOME with me? :-p
[10:54] <dholbach> seb128 will be able to relax a bit and take it easy :)
[10:55] <Hobbsee> seb128: now, while i'm tempted.....
[10:55] <crevette> Sounds fun
[10:55] <mvo_> Hobbsee: seb128 will move to wbuntu (windowmaker ubuntu - he runs that anyway)
[10:55] <Hobbsee> mvo_: ahhhhh....
[10:55] <seb128> mvo_: ;-)
[10:55] <Hobbsee> seb128: i wouldn't midn doing that - if i actually knew gnome, etc.
[10:56] <crevette> ah I thought he was using screenubuntu
[10:56]  * mvo_ hugs seb128
[10:56]  * dholbach hugs seb128
[10:56]  * Hobbsee --> dinner
[10:56] <seb128> Hobbsee: time to start learning about it then, maybe in some months you will be ready ;-)
[10:56] <crevette> Hobbsee, actually nobody knows wht is gnome
[10:56] <seb128> Hobbsee: enjoy your dinner
[10:56] <crevette> except this is people
[10:56]  * seb128 hugs dholbach mvo
[10:56] <njpatel> hmm, I just updated and now only root can play audio :-/
[10:57] <crevette> seb128, I've received svn account \./
[10:57] <njpatel> oh, and morning :-)
[10:57] <crevette> njpatel, not GNOME
[10:57] <crevette> bash pulseaudio
[10:57] <crevette> :)
[10:57] <njpatel> crevette: gnome :-)
[10:57] <njpatel> crevette: is there a fix for it?
[10:59] <crevette> actually I don't really know, I hasd problem when while 2 users where connected, the 2nd didn't had sound
[11:00] <njpatel> well, running pulseaudio as root seems to let normal apps work, which okay for now i guess
[11:03] <seb128> you should not have to workaround bugs this way
[11:03] <seb128> try asking on #ubuntu-devel maybe, and give details on what you updated, etc
[11:08] <njpatel> seb128: sure, i'm just trying to see if theres a bug filed first. I needed to get it working asap as I can't hack without music :-)
[11:12] <crevette> njpatel, are you sure you're in audio group ?
[11:12] <crevette> just a dumb thought, I'm not using ubuntu right now
[11:12] <njpatel> crevette: I just added myself, and now it works again
[11:12] <crevette> ahhahaha
[11:12] <crevette> :)
[11:12] <crevette> $
[11:13] <njpatel> it was wokring before the update...i wonder what happened
[11:14] <seb128> what update did you do?
[11:14] <seb128> dapper to hardy?
[11:16] <njpatel> seb128: nope, was already on hardy, it was just a normal update (about 30 packages)
[11:16] <seb128> weird then
[12:29] <Hobbsee> seb128: yeah, maybe.  i should be finished university by then.  Actually, i was thinking of doing that this release cycle, and stepping away from MOTU
[12:29] <Hobbsee> crevette: oh?
[12:29] <Hobbsee> seb128: besides, canonical wouldn't hire me - have caused too much trouble wiht MOTU, etc.
[12:31] <Hobbsee> seb128: either way, i'm interested, if i find time somewhere in there.  i'ts on the very long to-do list
[12:31] <Amaranth> Hobbsee: Hehe
[12:32] <Hobbsee> mvo: i don't know about your compiz change, btw....
[12:32] <Amaranth> Well, on one hand I don't want to think that is true but on the other hand I applied for that position so.... :)
[12:32] <Hobbsee> Amaranth: heh
[12:33] <mvo> Hobbsee: hm?
[12:34] <Hobbsee> mvo: a few of my apps (pidgin x1, firefox x many) keep going dark, sometimes not recovering.
[12:34] <Amaranth> Hobbsee: did they freeze?
[12:34] <Amaranth> nothing in that part of the code has changed
[12:35] <Hobbsee> Amaranth: er, yes.  isn't going dark usually freezing?
[12:36] <Amaranth> well, some people used to complain about firefox going dark and not actually freezing
[12:36] <Amaranth> which i think was a ff2 bug with it not responding to pings anymore
[12:49] <crevette> Hobbsee, why "ho ?"
[12:50] <Hobbsee> crevette: as in, "what do you mean?"
[12:51] <Hobbsee> Amaranth: ah right.
[13:46] <seb128> mpt: hey
[13:47] <mpt> hi seb128
[13:48] <seb128> mpt: do you know if there is a launchpad bug about the counts of bugs being different when changing the sorting option?
[13:49] <mpt> seb128, yes, and yes
[13:49] <seb128> ok, I can't find it, must be using the wrong keywords
[13:49] <mpt> bug 148901
[13:49] <ubotu> Launchpad bug 148901 in malone "fewer bugs listed when sorting" [High,Confirmed] https://launchpad.net/bugs/148901
[13:49] <seb128> sorting by recently open is nice for triaging
[13:49] <mpt> It's the #1 result when I search for "sort"
[13:50] <seb128> but if it's dropping bugs on the way that defeat the purpose
[13:50] <seb128> I searched for number and count ...
[13:50] <seb128> thanks!
[13:50] <mpt> np
[13:51] <seb128> how can this bug be open for 6 months and being ignored
[13:51] <mvo> which one?
[13:51] <seb128> mvo: bug #148901
[13:51] <ubotu> Launchpad bug 148901 in malone "fewer bugs listed when sorting" [High,Confirmed] https://launchpad.net/bugs/148901
[13:52] <mvo> heh :)
[13:52] <seb128> mvo: when you sort bugs there is some removed of the list
[13:52] <mvo> I always wondered by the numbers are different then
[13:52] <seb128> which means we might be ignoring important issues
[13:52] <mvo> (when i sorted e.g. update-manager reports)
[13:52] <mvo> right
[13:52] <seb128> what I'm wondering is which bugs it's removing
[13:52] <seb128> because it that's incomplete ones that ok, but if it removes valid bugs it's really broken
[13:53] <mvo> agreed, maybe #launchpad knows?
[13:53] <seb128> mpt: do you know what is the best way to get that escalated so the launchpad team might consider it for 2.0?
[13:54] <seb128> or whatever the next version is called
[13:54] <mpt> The next version is called 1.2.4
[13:54] <seb128> ok
[13:54] <seb128> so to get it consider for 1.2.4 or 1.2.5 ;-)
[13:54] <mpt> and the best way is probably to talk with the Launchpad managers (kiko, SteveA, and Rinchen)
[13:55] <seb128> ok, thanks
[14:56] <seb128> mvo: around?
[14:58] <mvo> yes
[14:58] <seb128> mvo: could you look at bug #220761? it seems to run several time the update-manager postinst and hit segfaults
[14:58] <ubotu> Launchpad bug 220761 in evolution "package evolution-common 2.22.1-0ubuntu3 failed to install/upgrade: subprocess post-installation script returned error exit status 139" [Undecided,New] https://launchpad.net/bugs/220761
[14:58] <mvo> looking
[15:00] <mvo> seb128: happens in a bunch of packages, I suspect its either a HW problem (bad ram) or the scrollkeeper-update bug we talked aobut the other day
[15:01] <mvo> I mark it a duplicate of #220762 fo rnow
[15:01] <seb128> mvo: how come it doesn't write what binary is segfaulting btw?
[15:01] <seb128> mvo: thanks
[15:01] <seb128> bug #220762
[15:01] <ubotu> Launchpad bug 220762 in ubuntu-docs "package ubuntu-docs 8.04.2~hardy failed to install/upgrade: subprocess post-installation script returned error exit status 139" [Undecided,Incomplete] https://launchpad.net/bugs/220762
[15:01] <mvo> yeah, I was wondering about that too
[15:01] <mvo> no idea right now
[15:02] <seb128> ok
[15:02] <mvo> (sorry)
[15:05] <seb128> (no need to)
[15:13] <mvo> heh :)
[17:40] <crevette> hello
[17:41] <cody-somerville> Hi