[00:06] <ScottK> slangasek and cprov: Thanks.
[00:41] <kees> doko: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38562
[00:45] <arthur-> kees: perhaps also useful to add the preprocessed log_event.cc as well
[00:45] <kees> arthur-: good idea, I will add that
[00:46] <doko> kees: please could you update the field keywords to wrong-code, known to work to 4.3.2 and known to fail to 4.3.3 4.4.0, and prefix the subject to [4.3/4-4 regression] ?
[00:46] <doko> I'm not allowed to do so
[00:46] <StevenK> doko: I note boost 1.3{6,7} don't exist in Jaunty currently.
[00:47] <kees> doko: done
[00:47] <StevenK> doko: I wanted a working schroot on armel, which is why I uploaded the workaround. Would you like me to revert it?
[00:47] <doko> StevenK: yeah, maybe needs a sync after the alpha release
[00:48] <arthur-> kees: 4.4 rather than 4-4 ;)
[00:48] <StevenK> I didn't think it had updated in Debian ...
[00:48] <StevenK> It hasn't
[00:48] <kees> arthur-: I was wondering about that.  :)
[00:49] <arthur-> kees: yeah, doko does so much typos ;p
[00:57] <StevenK> doko: However, schroot is universe, so we can just play now, if you want.
[00:59] <kees> arthur-: no difference in -E output between -O1 and -O2 (as I suspected).  is it still useful to attach the -E output?
[01:03] <arthur-> kees: -E doesn't run compiler, so optimization level doesn not influ on it, and yes it is, much easier to check if the bug is fixed from it after or even to extract a testcase
[01:04] <kees> okay, adding
[01:30]  * calc is at the LOCO meeting in a reasonably authentic british pub
[01:32]  * ogra wonders if "reasonable" means a union jack on the wall or guiness in bottles :)
[01:34] <calc> they have beer and stuff and fish and chips that seem about like at morpeth
[01:34] <calc> my wife got fish and chips at a regular seafood place here in the US and it wasn't anything like the pub stuff
[01:34] <ogra> heh, i was just kidding
[01:34] <calc> :)
[01:35] <ScottK> slangasek: Just did a kubuntu-meta upload that I think will get us back under the size limit.
[01:35] <ogra> kubuntu on diet :)
[01:35] <slangasek> ScottK: great, I'll set the CD builder up to watch for it
[01:36] <calc> what is the name of the gnome timekeeping app?
[01:36] <ogra> hamster
[01:37] <calc> ogra: you sure about that? i don't see a package
[01:37] <calc> ah hamster-applet
[01:37] <ogra> hamster-applet
[01:37] <calc> ok thanks :)
[01:37] <ogra> :)
[01:37] <slangasek> how... intuitive?
[01:37] <ogra> lol
[01:38] <calc> i did a dpkg -p hamster instead of doing a apt-cache search
[01:40] <Nafallo> baah. I use Tomboy for that :-P
[01:40] <calc> wow we have 8 people here so far, a record turn out i think ;-)
[01:46] <calc> dumb pub moved us under speakers and then cranked the volume to max
[01:46] <calc> can't even hear myself think
[01:48] <ogra> you got IRC who needs to hear ... just make the others fire up their laptops
[01:49] <calc> there is only two other people with laptops i think
[01:49] <calc> i think they aren't really geeks just pretend geeks ;-)
[01:53] <calc> there is someone here giving out linux journal swag but apparently doesn't work for them
[02:13] <ScottK> slangasek: Would you please remove kdeplasmoids kdeplasmoids-dbg kdeplasmoids-data - They are all transitional packages that can safely die.
[02:14] <slangasek> ScottK: are they NBS? they aren't showing up in the latest report yt
[02:14] <slangasek> yet
[02:15] <ScottK> They are.  The kdeplasma-addons upload I did a couple of hours ago was missing them (by design).
[02:15] <slangasek> ok
[02:15] <ScottK> You'll see the version they show up under uninstallable isn't the current one for that package.
[02:16] <slangasek> done
[02:17] <ScottK> slangasek: That will leave just plasmoid-quickaccess and libplasma2 uninstallable for KDE packages.  Both those can be binary demoted to Universe.  The libplasma2 -> libplasma3 transition will take a while to complete.
[02:17] <ScottK> slangasek: Thanks.
[02:18] <slangasek> hmm, are they uninstallable because they depend on universe packages, or non-existent packages?
[02:18] <slangasek> I don't see the point in demoting them if they're uninstallable regardless
[02:18] <ScottK> rsibreak is screaming at me.
[02:19] <ScottK> If a vanish for half a minute, that's why
[02:19] <ScottK> libplasma2 is uninstallable.
[02:19] <ScottK> plasmoid-quickaccess will eventually get ported to libplasma3, so leaving it is probably best.
[02:20] <slangasek> ok; I'd just as soon leave libplasma2 on the main uninstallables list as anywhere, then - or else NBS it out directly
[02:20] <ScottK> Let's leave it then.
[02:20] <StevenK> The NBS list currently makes me cry
[02:21] <slangasek> StevenK: I've done a pass earlier today, I just haven't refreshed the list because I can never remember where to do it
[02:40] <emet> flashplugin-nonfree seems to be broken
[02:41] <calc> jcastro: i'm going to try to give your ontario speech but its really loud here so not sure if its going to work well :-\
[02:41] <calc> jcastro: and no projector
[02:42] <rlaager> pitti: Something I forgot to suggest at UDS... It seems to me that Apport & Launchpad should conspire together, as appropriate, to set the "affects me" flag for people filing duplicate crash reports. This may not have to be Apport-specific, though, as it seems you'd want that for anyone saying, "yes, that's my bug".
[02:43] <calc> rlaager: aiui it already does that
[02:43] <calc> rlaager: at least if they are similar enough
[02:43] <rlaager> Hmm. I don't recall seeing it do so, but I suppose I could've missed it.
[02:43] <calc> rlaager: well no but it consolidates duplicates
[02:43] <calc> rlaager: so you are correct
[02:43] <calc> rlaager: so yea doing a me too instead would be better
[02:44] <jcastro> calc: steal as much as you like
[02:44] <calc> jcastro: heh :)
[02:46] <ScottK> Well it doesn't even default to 'affects me' when you report the bug, so I doubt it does it for dupes.
[02:49] <ScottK> slangasek: Any idea how long until there's a new Kubuntu CD image?
[02:49]  * ScottK isn't sure how to keep track of the process.
[02:50] <slangasek> ScottK: alternate and livefs both building right now; so should be < 1h
[02:50] <ScottK> slangasek: Thanks.
[03:30] <avb> guys, is there is any ideas why /bin/sh is still a symlink to /bin/sh
[03:30] <avb> to /bin/bash
[03:30] <avb> instead of having regular sh, which is way faster
[03:32] <Hobbsee> sarah@neptune:~% ls -la /bin/sh                                          2:32PM
[03:32] <Hobbsee> lrwxrwxrwx 1 root root 4 2008-09-12 15:04 /bin/sh -> dash
[03:33] <avb> $ ls -l /bin/sh
[03:33] <avb> lrwxrwxrwx 1 root root 4 2008-02-06 19:02 /bin/sh -> bash
[03:33] <avb> i was not changing nothing manually
[03:33] <ScottK> avb: What release are you running?
[03:33] <avb> 8.10
[03:33] <Hobbsee> i think you've done something to your system - the default changed a few releases ago
[03:34] <avb> i case i was not making clean installs
[03:34] <ScottK> avb: New install or upgraded from earlier?
[03:34] <avb> for a couple of releases
[03:34] <ScottK> That may be  the reason.  IIRC that change was made on install, not upgrade so stuff already there wouldn't get broken.
[03:34] <avb> i see
[03:34] <avb> # update-alternatives --config /bin/sh
[03:34] <avb> No alternatives for /bin/sh
[03:34] <ajmitch> not sure if that started with dapper or edgy
[03:34] <avb> thats another issue
[03:35] <avb> should i fill a bug?
[03:35] <avb> i just checked system dash is already there
[03:35] <avb> but in postinst it havent made update-alternavites
[03:35] <ScottK> avb: No, it's by design.  /bin/sh is just a symlink.  Change it.
[03:36] <avb> thats a case, why new install have dash, and dist-upgrade dont
[03:36] <avb> ScottK, but its realy looks like a bug, not like a design
[03:36] <avb> probably lets change the design a bit? :)
[03:37] <avb> i can submit patch if needed
[03:37] <avb> not a big deal
[03:37] <ScottK> avb: Because an existing system may have third party stuff on there we can't know about and we are conservative about breaking stuff on upgrades.
[03:37] <ScottK> No, this is on purpose to be careful with not causing breakage on upgrade.  This is a feature and no bug.
[03:38] <avb> heh
[03:38] <avb> thats realy weird behavoir. once we are moving from upgrades to reinstalls
[03:38] <avb> smells like 2nd windows
[03:39] <avb> anyway, any 3rdparties should be informed once they bashing once interpriter is set to /bin/sh
[03:40] <ScottK> There's a lot of config stuff that doesn't get touched on upgrade.
[03:40] <ScottK> Postfix configs for another one.
[03:42] <avb> yes, i will be more then happy if it will be just bash
[03:42] <avb> :)
[03:43] <avb> i dont have my splash since breezy :)
[03:43] <avb> anyway i disabled it, but still
[03:43] <avb> then it was a network-manager and couple of other stuff
[03:59] <ScottK> slangasek: Is 20081218.2 the one I should be looking at or is it not published yet?
[04:00] <ScottK> slangasek: I'm likely to head to bed soonish and I'd really like to know if anything else needs to be whacked out of there.
[05:06] <slangasek> ScottK: hrm, yes, .2 was the build in question
[05:06] <slangasek> ScottK: for desktop, anyway
[05:06] <ScottK> slangasek: OK.  Then apparently I suck.
[05:07] <slangasek> what went wrong?
[05:08] <ScottK> http://cdimages.ubuntu.com/kubuntu/daily-live/20081218.2/ says still oversize.
[05:08] <slangasek> no idea why, yet?
[05:08] <ScottK> I know why some stuff got bigger.
[05:09] <slangasek> the .1 and .2 builds have identical livefs on them
[05:09] <slangasek> did the livefs build fail?
[05:09] <ScottK> Dunno.  I'm pretty new to this part of things.
[05:10] <slangasek> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/kubuntu/
[05:10] <slangasek> full-sized build logs for 20081218.1 (yes, the livefs serials aren't guaranteed to match the CD serials)
[05:11] <ScottK> OK.
[05:11] <slangasek> so, the livefs build didn't fail at least
[05:12] <slangasek> kubuntu-desktop 1.105 is present in all the images
[05:12] <ScottK> slangasek: That one was built with kubuntu-meta 1.05, not 1.06,
[05:12] <ScottK> 106 is what we wanted.
[05:12] <slangasek> ... oh.
[05:13] <slangasek> sorry, when I looked 106 wasn't visible in LP yet, I had assumed 105 was correct :/
[05:13] <slangasek> ok, re-triggering
[05:13] <ScottK> Finding something that had a version number in it helped a lot.  Thanks for the pointer.
[05:14] <ScottK> slangasek: Next question: is getting proper builds on armel something worth uploading stuff for now?
[05:14] <slangasek> yah, sorry for not checking the version number with you explicitly earlier :/
[05:14] <ScottK> NCommander is confident he finally has kde4bindings (which is the key to most of Kubuntu Desktop) figured.
[05:15] <NCommander> It builds fine
[05:15] <NCommander> I'm just tweaking some of the install rules
[05:15] <ScottK> It'd take an upload of kde4libs, python-qt4, and kde4bindings to fix.
[05:15] <slangasek> well, I didn't have any intention of releasing armel images for alpha-2 yet
[05:15] <ScottK> OK.
[05:15] <NCommander> ScottK, hold on, I'm still making rules changes
[05:15] <ScottK> I'll hold it until after the milestone then.
[05:15] <slangasek> sounds good
[05:16] <ScottK> NCommander: No problem.  That sounded like don't do it from the RM to me.
[05:24] <ScottK> slangasek: The changes I did for that upload should save north of 40MB.  They'll do for alpha2, but not for the long run.
[05:32]  * slangasek nods
[05:33] <slangasek> ScottK: amd64 alternate is still a hair oversized :(
[05:34] <ScottK> Gumble.
[05:34] <slangasek> 2624K, to be exact
[05:36] <ScottK> slangasek: Are the others OK
[05:36] <slangasek> alternate i386
[05:36] <slangasek> livecd always takes longer to build, so I don't know ye
[05:36] <slangasek> t
[05:36] <ScottK> OK.
[05:45] <ScottK> slangasek: You didn't put the publisher on manual did you?
[05:45] <slangasek> no
[05:45] <ScottK> We got plasmoid-quickaccess fixed for libplasma3, but the binaries have been sitting unpublished for over an hour.
[05:46] <ScottK> I was hoping to put that back (it's only 68K)
[05:46] <ScottK> Grumble's more.
[05:46] <slangasek> hmm
[05:49] <slangasek> ScottK: looks like the hourly job from 2h ago overran and as a result, the last hourly job failed on the lock
[05:49] <ScottK> Thanks.  Patience then.
[05:57] <kirkland> what's the new package queue url in launchpad?
[05:57] <slangasek> /ubuntu/jaunty/+queue, I believe
[05:57] <kirkland> slangasek: thx
[06:03] <slangasek> ScottK: liveCD built, and the /only/ difference in the livefs contents is the kubuntu-desktop version
[06:04] <ScottK> slangasek: Built fits?
[06:04] <slangasek> oversized, since there was no other reduction to the livefs contents
[06:05] <ScottK> slangasek: OK.  So I found the 2624K for the amd64 alternate.
[06:05] <ScottK> How much more do we need?
[06:06] <slangasek> for desktop?  were the previous changes not expected to have an effect on desktop CD size?
[06:07]  * ScottK is confused he thinks.
[06:07] <ScottK> The amd64 alternate was 2624K over, but i386 fit.
[06:07] <slangasek> yes
[06:07] <slangasek> desktop just built, and the results are that nothing changed in the livefs except for the kubuntu-desktop version
[06:08] <slangasek> so, still oversized by ~40MB
[06:08] <ScottK> OK.  That's odd.
[06:08] <ScottK> So the alternate shrank, but live didn't?
[06:08] <slangasek> correct
[06:09] <ScottK> Odd
[06:09] <persia> Did the task change as well as the metapackage?  I seem to remember this sometimes taking an extra cycle for timing reasons.
[06:10] <slangasek> appears to be an issue of the Task: field not having updated yet for these packages in the archive
[06:10]  * ScottK looks at the logs
[06:11] <slangasek> it should right itself with the next publisher run; I guess we haven't had enough publisher runs yet, probably due to overruns
[06:11] <ScottK> OK.
[06:14] <ScottK> slangasek: I think I have enough shrinkage to cover the 2624K.  If I upload that and go to be, can you just pitch language packs off the live until it fits if needed?
[06:14] <ScottK> go to be/bed.
[06:14] <slangasek> can do, yes
[06:15] <ScottK> slangasek: OK.  107 uploaded.  I'm off to bed.
[06:15] <slangasek> 'night
[06:33] <ebroder> In researching LP #305001, I noticed that python-elixir and python-sasync both ship versions that can't work with the python-sqlalchemy in Hardy. Should I fix this through -backports or try to get them SRU'd?
[06:34] <persia> ebroder, If they truly can't work, it would be an SRU, although you should be seeking the minimal patch to make them work.
[06:36] <ebroder> Oh wait...I may be lying about python-elixir. I need to do more research
[06:37] <ebroder> persia: So I should try to do this by attempting to extract the necessary patch to add compatibility for sqlalchemy? That's substantially more work and more likely to regress than just pulling the newer version...
[06:38] <persia> ebroder, I'll agree on the more work part.  Whether it is more likely to regress is probably a matter of the final resulting patch size.  I'm not in an SRU approval team, but if you're sure it's worse to make a patch, you'll want to state your argument very carefully, and be absolutely sure there isn't some small patch that works.
[06:39] <ebroder> persia: Yeah...I'm not actually willing stand by that assertion. I don't use the packages myself, so I'll file the bug - maybe someone who cares will deal :-P
[07:11] <Tonio_> hi
[07:39] <slangasek> doko_: looking at the changelog, there used to be a python-numpy-ext package split off, and you merged it in?
[07:40] <doko_> slangasek: can't remember ... looking ...
[07:40] <slangasek> it was a while ago :-)
[07:43] <doko_> slangasek: hmm, have to look ... but probably not in time for the alpha
[07:44]  * slangasek nods
[07:45] <slangasek> fwiw, I'm currently poking at it because I don't see anywhere else that I can claim back even close to that amount of space, and amd64 is oversized
[07:45] <slangasek> so if nothing else, I may have a patch for consideration in the next hour or so
[07:50] <doko_> lapack_lite.so could be split off, but I'm unsure about _dotblas.so which is in core
[07:50] <doko_> splitting the .py and doc files doesn't save much
[07:52] <doko> slangasek: how do you get rid of _dotblas.so?
[07:52] <dholbach> good morning
[07:52] <slangasek> doko: dotblas.so is easy, it's only loaded opportunistically
[07:52] <slangasek> # try to import blas optimized dot if available
[07:52] <slangasek> try:
[07:53] <slangasek> lapack_lite actually seems to be hooked deeper, there are a lot of references to linalg
[07:55] <doko> omitting the tests or oldnumeric doesn't save much
[07:56] <slangasek> well, getting rid of fortran will save a lot
[07:57] <doko> why is setup.py packaged?
[07:57] <slangasek> I... don't know :)
[07:59] <slangasek> hrm, the hooks into lapack_lite/linalg are way too deep for this to be even a remotely "quick" fix
[08:01] <doko> slangasek: maybe have an -ext package with the lapack_lite linked with fortran, which diverts the lapack_lite in a reduced -numpy package, and then build lapack_lite with the included *_lite.c files?
[08:01] <slangasek> so lapack_lite is buildable in some reduced, non-lapack form?
[08:03] <slangasek> hmm, looks like that could work, after all
[08:03] <slangasek> but I don't think I would succeed in getting it to build at this hour
[08:19] <doko> slangasek: hmm, maybe for a quick solution, just drop the b-d on lapack and blas and build it this way?
[08:20] <slangasek> doko: ok with me; I guess we need to remember to revert that after the alpha?
[08:25] <doko> slangasek: yes, bug report for the reminder should be fine. but I can only upload later today
[08:25]  * slangasek nods
[08:36] <mvo> slangasek: thanks for the fix in deskbar-applet!
[08:36] <slangasek> mvo: n/p
[08:54] <slangasek> ScottK: looks like we just need to drop the Japanese langpack from desktop/i386 and we're set
[09:22] <dholbach> doko, DktrKranz: what do we do about bug 195407?
[09:29] <DktrKranz> dholbach: I haven't tried, but there were some discussions on debian remote watch
[09:30] <dholbach> DktrKranz: aha
[09:34] <DktrKranz> dholbach: I'm unsure how to proceed, since Debian side stalled a bit (latest update was in early 2007, IIRC)
[09:35] <dholbach> DktrKranz: maybe doko knows
[09:38] <norsetto> dholbach: DktrKranz: morning gents!
[09:39] <dholbach> hiya norsetto my friend :)
[09:40] <highvoltage> he's come to speak with you again
[09:41] <highvoltage> (that sound-of-silence reference was a bit too weak)
[09:41] <DktrKranz> hi norsetto, Master of Rivers
[09:42] <norsetto> highvoltage: hi to the other side of the globe too ;-)
[09:43] <highvoltage> norsetto: hi :D
[11:41] <cjwatson> liw: at your convenience (and perhaps after alpha 2), could you cause there to be a new upload of system-cleaner to jaunty (even if it's no-change)? A Soyuz bug has meant the Architecture: all binaries have gone missing from armel's Packages files; we've encountered this before with binaries copied from -updates and it's been raised with the Soyuz team, but for now a reupload is the simplest solution
[11:42] <cjwatson> could somebody score up debian-installer a bit on armel? I'd like to know whether it'll build before Saturday
[11:45] <liw> cjwatson, ack, will do
[11:46] <liw> now would be a good time to re-visit the question of the software's name -- "Cruft Remover" turns out to be a bad name
[11:48] <cjwatson> I thought cruft was a non-jargon word too but apparently I was wrong. I think I was thinking of "lint", which is the stuff you pick off clothes
[11:49] <cjwatson> I'm in favour of (almost) anything that allows us to stop endlessly wasting time on naming arguments
[11:49] <davmor2> liw: just call it lint remover
[11:50] <liw> I'd like to change the word "remover" as well, since not everything the program does is remove things, sometimes it adds them too
[11:50] <davmor2> just read cjwatson's reply like minds
[11:50] <liw> the word "janitor" keeps bouncing inside my skull
[11:50] <liw> but yeah, I would prefer to not re-visit this question, either
[11:51] <ScottK> The last Kubuntu live CD came out slightly over-size on i386.  I've adjusted language packs, so I think it's good. Would someone please kick off another CD build?
[11:51] <NCommander> hey ScottK
[11:52] <cjwatson> ScottK: which seed(s) did you change?
[11:52] <cjwatson> oh, hey, I could just look
[11:52] <NCommander> morning cjwatson
[11:52] <cjwatson> morning
[11:53] <ScottK> cjwatson: Kubuntu live
[11:53] <ScottK> Or more specifically, kubuntu.jaunty live.
[11:53] <ScottK> NCommander: Heya.
[11:53] <NCommander> how goes it this morning?
[11:53] <cjwatson> ScottK: hmm, when? last commit was 0855 UTC by Steve
[11:54] <ScottK> cjwatson: OK.  Or I didn't.
[11:54]  * ScottK looks.
[11:55] <ScottK> cjwatson: It looks to me like he and I made the same change, but I hadn't updated.  It also looks like he didn't respin the CD unless one is in progress now.
[11:56]  * ScottK doesn't know how to tell about that.
[11:57] <cjwatson> he may have had to wait for a publisher run
[11:57] <cjwatson> there's nothing in progress right now (the logs are published so in principle you could tell from that, but they're only mirrored hourly)
[11:58] <cjwatson> I've kicked off a build now
[11:58] <ScottK> cjwatson: Thanks.
[11:58]  * ScottK sits back and tries to figure out how he got in charge of making Kubuntu fit on the CD during Riddell's vacation.
[11:58] <cjwatson> liw: (did "System Janitor" ever come up as a suggestion?)
[11:59] <cjwatson> ScottK: just lucky :-)
[11:59] <ScottK> ;-)
[11:59] <cjwatson> liw: oh, https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-November/006139.html
[11:59] <liw> cjwatson, someone did suggest System Janitor, but to me, it's uncomfortably close to System Cleaner
[12:00] <cjwatson> liw: I don't think you need to avoid "System X"
[12:00] <cjwatson> "System Cleanser" does seem too close for comfort
[12:00] <NCommander> cjwatson, am I correct in thinking that we're almost out of alpha 2 freeze :-)?
[12:00] <ScottK> System Decruftifier
[12:00] <cjwatson> NCommander: we'll be out of it when Steve sends the release announcement
[12:00] <cjwatson> decruftifier> oh god no :)
[12:00] <NCommander> :-(
[12:01]  * NCommander listens to black hole sun
[12:03]  * NCommander pictures cjwatson with some sorta giant cruft bufter gun dressed as a terminator
[12:03] <NCommander> ....
[12:03] <NCommander> I'm not sure if thats scary or awesome :-P
[12:03] <NCommander> s/bufter/buster/g
[12:07] <mdz> bryce: in your 'should be' diagram, the hal-addon-acpi line should be solid, not dashed
[12:08] <ays> guys, one simple question... in order for someone who's been win based developer and would like to migrate to Linux development, which programming lang and ide would you suggest that he use?
[12:11] <cjwatson> that isn't a simple question because it depends on their experience and (perhaps much more strongly) on what they want to do.
[12:12] <ays> ah... well, I can tell you some stuff, for example, I've been developing mostly with c#, for about 3-4years now
[12:12] <ays> before c#, I used c,c++ and somewhat java
[12:13] <ays> the logical answer would be c++, but I really do not know, how much c++ is used in linux development and linux apps development...
[12:13] <ScottK> It's used a lot in KDE.
[12:14] <azeem> Qt is C++, GTK is C, but there are some C++ GTK apps as well
[12:15] <ays> ScottK I read about c++ and KDE, but, since I'm using gnome and prefer my Linux not to look like Win...
[12:16] <ScottK> Well C# is pretty much C# if you like such things.
[12:17] <ays> I dont like c#, to be honest... I did like Visual Studio and stuff that it does and how it makes you less code... and I have to use it, for now, to make living... what about java and/or python?
[12:17] <ays> I aint really familiar with python, heard only great stuff about it... and java is something I know already
[12:17] <azeem> ays: do you want to start a new project, or contribute to existing projects?
[12:18] <azeem> you can use all of those languages for writing GNOME applications, though I am not sure Java-based GNOME apps are accepted officially
[12:19] <ays> well... at this point, I don't think Im good enough to contribute to ubuntu community in development ways... so... when I get somewhat better in linux based development, I'd like to try to help and contribute in any way, either with current on with new projects
[12:19] <ScottK> In Ubuntu, Python tends to be the language of preference for internal projects.
[12:19] <ays> or*
[12:23] <NCommander> ScottK, is there any major Ubuntu tool that isn't written in python?
[12:23] <NCommander> (aside from the wiki, which I believe is perl based)
[12:24] <StevenK> NCommander: Upstart
[12:24] <NCommander> right
[12:24] <NCommander> But thats kinda out of necessity ;-)
[12:25] <ays> basically... it all comes down to python...  regarding ubuntu, but what about creating apps for all linux platforms, for example, pdf reader or something like that?
[12:26] <azeem> ays: see above
[12:27] <ays> c++ and python then... I thought so, but had to check... thank you all for the help. :)
[12:32] <cjwatson> ays: for the most part you can carry on using languages you're comfortable with, but you will likely have to learn new sets of runtime libraries. As for IDEs, well personally I'm old-school and use vi and make, but I hear that things like eclipse and anjuta are popular.
[12:33]  * persia plugs netbeans
[12:34] <ScottK> cjwatson and slangasek (when he wakes): It fit.  So all 4 Kubuntu images fit now.
[12:34] <ScottK> cjwatson: Thanks.
[12:35] <Koon> doko: I just tested jvm.cfg-default. It installs as /usr/lib/jvm/java-6-openjdk/jre/lib/$arch/jvm.cfg-default, is it by design ? Tools like keytool (ca-certificates-java) or jsvc (tomcat) apparently only look for "jvm.cfg"
[12:35] <ays> cjwatson thanks mate, I'll check 'em out
[12:36] <cjwatson> ScottK: cool
[12:37] <doko> Koon: there's a patch (debian/patches/default-jvm-cfg.diff) to look for this file (which is not installed as a config file)
[12:38] <Spads> NCommander: the wiki is not Perl
[12:38] <NCommander> I thought it was
[12:38] <Koon> doko: ok, looking
[12:40] <Koon> doko: then we should probably also teach jsvc to look for this file
[12:41] <doko> Koon: I see, the jdk has a second copy, which is still unpatched ...
[12:42] <Koon> doko: jsvc (commons-daemon) directly parses what's on the filesystem and explicitely looks for jvm.cfg, so I guess it needs to be taught about jvm.cfg-default
[12:43] <Koon> I'll investigate that, there might be another way around it
[12:44] <doko> Koon: in this case, maybe assume just a default configuration?
[12:45] <Koon> doko: yes, theorically jsvc accepts a -jvm parameter to explicitely set the libjvm.so without looking at the conf file
[12:46] <Koon> though that seems to be buggy. I need to go deeper into that
[12:46] <Koon> doko: otherwise that sounds like a great solution to our problem, thanks :)
[12:47] <ScottK> Would whoever updates the iso qa tracker please add http://cdimages.ubuntu.com/kubuntu/daily-live/20081218.5/ i386 and amd64?
[12:47] <doko> Koon: -server seems to be safe choice, it's available on every platform/architecture
[12:47] <Koon> doko: yes, and that's one of the few jsvc doesn't even try to find :) It tries client, classic...
[12:48] <soren> NCommander: Could you be pursuaded to take a glance at libaio? It's failing on all but the official architectures, and I haven't a clue where to start fixing it.
[12:49] <NCommander> link?
[12:49] <soren> Well, I probably do, actually, but it's easier to pretend not to.
[12:49] <soren> https://edge.launchpad.net/ubuntu/jaunty/+source/libaio/0.3.107-1ubuntu1
[12:50] <NCommander> soren, amazing, it built on the itatinic
[12:50] <soren> NCommander: It'll probably fail at runtime.
[12:51] <soren> NCommander: Most of the test cases fail.
[12:51]  * NCommander winces
[12:51] <NCommander> I don't think I even want to look at the code that could generate that build failure
[12:52] <soren> Of course you do.
[12:52] <soren> You like pain. We all know that.
[12:52]  * NCommander hurts soren :-P
[12:52] <soren> Yes, I like pain, too. It's just that I'm into a different kind of pain these days.
[12:52] <NCommander> ....
[12:53]  * NCommander bleaches his brain
[12:56] <NCommander> soren, I think the test suite busted
[12:56] <NCommander> soren, amd64's test suite blew up miserably as well :-)
[12:57] <NCommander> the test suite is obviously not 64-bit clean
[12:58] <NCommander> anyway, any objections if I only test build on sparc once I fix it?
[12:58] <NCommander> (well, sparc/release archs)
[13:00] <soren> PRobably not.
[13:03]  * liw ponders "Janitor Service" as a name
[13:04] <NCommander> Oh
[13:04]  * NCommander hits his head
[13:04] <NCommander> I see what's going on
[13:05] <persia> liw, But it's not a service : it's a one-time thing, right?
[13:06] <liw> persia, that's a good point
[13:07] <NCommander> ah
[13:07] <NCommander> crud, if I'm right on this build failure, I'm going to hurt the author
[13:08] <liw> perhaps the naming problem is an indication that mpt is right and the whole program shouldn't exist and the functionality should be part of, say, update-manager
[13:09] <NCommander> soren, found your build failure
[13:09] <NCommander> /#warning Not really sure where kernel memory is.  Guessing.
[13:09] <NCommander> ;.;
[13:10] <liw> NCommander, *blink*
[13:10] <NCommander> That's code you DON'T want to see in a test suite
[13:11] <NCommander> oh I see
[13:11] <NCommander> It wants an invalid pointer ...
[13:16] <NCommander> soren, see -motu
[13:16] <soren> saw it
[13:16] <NCommander> Can we just be cheap and do the same fix :-)
[13:19] <soren> NCommander: Feel free to do the merge.
[13:19] <NCommander> I was just going to implement the change as ubuntu2
[13:19] <NCommander> That merge looks ugly
[13:19] <soren> It probably is.
[13:20] <NCommander> although merge-o-matic did give a merge that only had the usual control issue
[13:20] <NCommander> hrm
[13:20]  * NCommander does the merge instead
[13:21] <NCommander> Better fix
[13:21] <soren> \o/
[13:23] <NCommander> soren, merged
[13:23] <NCommander> That was easier than it looked :-)
[14:18] <ScottK> Is stgraber the right POC for iso tracker updates?
[14:21] <persia> ScottK, mostly, although #ubuntu-testing may have others.
[14:22] <ScottK> persia: Thanks.
[15:35] <gardier> hello I have a computer which has stopped working with the latest versions of many linux distros. When I looked into this it seems all the ones that don't work - including Ubuntu and Fedora use the same - probably current version of Xorg. What do I need to do about this? My offending hardware is Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
[15:35] <gardier> At least that's what grep reports
[15:37] <tseliot> gardier: this is not a support channel
[15:38] <tseliot> please file a bug report about it and define what you mean by "it doesn't work" in that report
[15:38] <cjwatson> unless you're able to hack X yourself, the best thing to do is to file a bug with as much information as you can; https://wiki.ubuntu.com/X/Debugging may help
[15:38] <cjwatson> see also https://wiki.ubuntu.com/X/Reporting linked from that
[15:39] <gardier> tseliot I mean X wont run from any medium live cd or installed
[15:39] <gardier> Until O go back to an older version of xorg
[15:40] <tseliot> gardier: please follow cjwatson's instructions
[15:40] <gardier> So I report it to Ubuntu not Xorg?
[15:41] <gardier> That's what I needed to know
[15:42] <gardier> OK thanks tseliot and cjwatson
[15:42] <tseliot> gradier: yes, report it against the package in Ubuntu. Then, if it's an upstream bug we'll add a link to the upstream report
[15:42] <gardier> cheers
[15:43] <gardier> seeya
[16:08] <nijaba> hello.  I've just noticed that python-dialog is not in main.  Is there a good reason for it not to, or is it something I can file a MIR on with confidence?
[16:10] <ScottK> nijaba: Why does it need to be in Main?
[16:11] <nijaba> ScottK: just evaluating if I could base some code that would eventually end up there with this dep, but I am looking for any better reco
[16:15] <dee> Hello. May I ask a question concerning compiling the Ubuntu Hardy kernel including the linux-ubuntu-modules? This is something I couldn't find anywhere and I hope that you developers have a hint.
[16:16] <mkrufky> dont ask to ask -- just ask
[16:16] <dee> :)
[16:16] <dee> I want to build linux-ubuntu-modules for my kernel but do not know how to say that I have a own kernel. It always tries to get the sources from the standard kernel.
[16:17] <mkrufky> so, my *unofficial* answer  (maybe some ubuntu folks will correct me if im wrong) .......
[16:17] <mkrufky> L-U-M should work when build against the ubuntu kernel
[16:18] <mkrufky> i dont know for sure that you can count on it working or building against a vanilla kernel
[16:18] <mkrufky> s/"vanilla"/"anything other than an ubuntu"
[16:19] <dee> Oh, it's not a vanilla-kernel. I just installed "linux-source" from repository
[16:20] <dee> and then after extracting in /usr/src: sudo cp /boot/config-2.6.24-22 .config
[16:20] <dee> sudo make-kpkg --initrd --revision i686moto binary
[16:20] <dee> I suppose that this should be the default Ubuntu Kernel, isn't it?
[16:21] <mkrufky> hmm, sounds like that is probably okay...
[16:21] <mkrufky> dee i bet there is documentation on how to do this in the wiki somewhere
[16:21] <mkrufky> i usually just do 'debuild' and it does everuything i need
[16:22] <mkrufky> (wiki link in channel topic, btw)
[16:22] <dee> yes the wiki is https://help.ubuntu.com/community/Kernel/Compile
[16:22] <dee> unfortunately I then have the problem described above.
[16:22] <cjwatson> #ubuntu-kernel would be better really
[16:23] <dee> cjwatson: thanks. didn't know they have an own room. I will ask there. :)
[16:26] <dee> thx & bye.
[16:49]  * jdong things ~we-love-pitti needs a PPA :)
[16:49] <jdong> you know... for wallpaper packs and screensavers.
[16:50] <ScottK> jdong: If you're bored we could use some help with testing Kubuntu for Alpha 2 ....
[16:50] <jdong> ooh perhaps later today I will be bored; I've got a long plane ride tomorrow too :)
[16:51] <jdong> any particular area that needs attention?
[16:51] <ScottK> jdong: It's pretty much all up for grabs http://iso.qa.ubuntu.com/qatracker/build/kubuntu/all - Some stuff's in progress, but the more the merrier.
[16:53] <jdong> ScottK: cool, will do
[16:53] <ScottK> Thanks.
[17:12] <davmor2> whose working on jockey now it doesn't seem to be detecting my nvidia gfx card in jaunty alpha 2 test iso
[17:14] <bryce> mdz, updated
[17:17] <slangasek> bryce: ^^ that nvidia/jockey issue isn't the same as the bug you errataed, is it?
[17:20] <bryce> slangasek: no, the issue that prompted the release note was that nvidia was causing X to get uninstalled
[17:20] <slangasek> haha
[17:20] <slangasek> so maybe jockey's smart enough to not do that?
[17:22] <bryce> if it isn't, it'd be a nice feature to have.
[17:22] <tseliot> slangasek, bryce: I could rebuild the nvidia packages so that the xorg abi is bumped. This however will only prevent Jockey from removing X. Users will still have to set the IgnoreABI option in the xorg.conf though
[17:23] <bryce> tseliot: if all that is done, does -nvidia work properly?
[17:23] <bryce> I'm really tempted to just recommend people not use the binary drivers, until we get new ABI-compatible blobs from them
[17:24] <tseliot> bryce: tjaalton tried either 180 or 177 and it worked. I haven't installed Jaunty on my desktop pc
[17:24] <tseliot> bryce: that's what I wanted to do
[17:25]  * bryce nods
[17:26] <tseliot> davmor2: if the modalias package can't be installed then jockey won't be able to detect your card.
[17:26] <bryce> yeah, I think in the ranking of degrees of badness, uninstalling X is probably pretty high.  Even if it results in a misconfigured -nvidia it'd be best that it not do that
[17:26] <bryce> tseliot, slangasek, tjaalton:  any way we could easily slip in a big fat warning/disclaimer for people using -nvidia?
[17:27] <slangasek> slip it in where?
[17:27] <bryce> like in jockey or the upgrader
[17:28] <slangasek> not easily, for alpha-2
[17:28] <davmor2> tseliot: do you want a bug report against it or is there one already?
[17:28] <tseliot> davmor2: it's well know already
[17:29] <tseliot> bryce, slangasek: we could drop the Recommends nvidia-common from jockey but this wouldn't solve the problem for current installations
[17:30] <tseliot> and users will try to install the nvidia drivers anyway
[17:33] <slangasek> tseliot: well-known to you, but having it in a bug report helps testers and gives us something to link to in the errata, e.g.
[17:34] <tseliot> slangasek: it's this bug report:
[17:34] <tseliot> https://bugs.launchpad.net/bugs/308410
[17:34] <slangasek> ok, cool
[17:35] <tseliot> ;)
[17:39] <ScottK> slangasek: Dunno how detailed your backscroll reading is so ....  Kubuntu live is no longer oversized and I got it added to the ISO tracker, so we're inprogress on testing.
[17:39] <slangasek> ScottK: yep, caught at least that much, thanks :)
[17:40] <cjwatson> but sounds like Kubuntu ubiquity's partitioning is screwed ...
[17:40] <cjwatson> (Evan's working on it)
[17:41] <ScottK> cjwatson: OK, so I guess focus on tests that don't need install from the LiveCD ...
[17:42] <davmor2> cjwatson: only manual
[17:42] <slangasek> evand: is that the same outstanding ubiquity issue you'd mentioned yesterday morning, or did that fix get uploaded and kubuntu manual partitioning is still broken?
[17:43] <cjwatson> davmor2: right, sorry
[17:44] <davmor2> cjwatson: install now on 32bit and 64 using guided whole drive
[17:44] <davmor2> s/install/installing
[17:45] <evand> slangasek: Yes
[17:45] <davmor2> cjwatson: actually if ubiquity needs modifying would it be worth my time testing these installs or should I just hit alt's instead for now?
[17:45] <slangasek> evand: yes to which part? :-)
[17:46] <evand> Same bug :)
[17:46] <ScottK> slangasek: MIRs for libio-pty-perl
[17:46] <evand> davmor2: Automatic should work fine
[17:46] <slangasek> ScottK: hmm?
[17:46] <ScottK> .... and libipc-run-perl are approved, so if those get promoted, lintian should be installable again
[17:47] <ScottK> Sorry, premature use of Enter.
[17:47] <ScottK> slangasek: ^^
[17:47] <slangasek> ah, great
[17:47] <davmor2> evand: it is but I thought that if you are modifying ubiquity then the cd will need a re-roll
[17:47] <slangasek> I'll have a look at those after I figure out whether I can safely demote libgc*mm*
[17:47] <slangasek> er, libg*mm*
[17:49] <slangasek> not without breaking cdrdao build-deps, sigh
[17:49] <slangasek> crimsun: should pulesaudio's recommends: of paprefs (in universe) be dropped?
[17:49] <evand> davmor2: I'm doubtful the changes I'm talking about will make it today.
[17:50] <tedg> slangasek: Are you demoting libgtkmm?  (I'm confused)
[17:50] <davmor2> no probs I'll carry on it'll be a smoke test any way if nothing else
[17:50] <slangasek> crimsun: it's pulling a lot of GNOME C++ libs into the CD that we don't otherwise need
[17:51] <slangasek> tedg: well, I'm trying to get libgconfmm, libglademm, libgnomeuimm off the CD, and thought dropping them to universe would be a quick fix if they aren't actually needed
[17:52] <slangasek> I guess I could still do that as a workaround and just leave cdrdao unbuildable for a bit
[17:52] <slangasek> but that's pretty fugly
[17:52] <tedg> slangasek: Ah, okay.  Those are much less used that gtkmm.  I was a touch worried about gtkmm.
[17:52]  * slangasek demotes libstdc++6
[17:52]  * slangasek whistles
[17:53] <tedg> Actually, I think the only one of those that's not deprecated is GConf.
[17:54] <slangasek> they're in main purely as a matter of build-dependencies for a package that builds both main and universe bits
[17:54] <bryce> ogra: classmate-tools still recommends xserver-xorg-video-i810 but that package is long gone.  Mind if I s/-i810/-intel/ in that package to clear the NBS?
[18:53]  * Keybuk reads about fsnotify() and pinches himself to make sure he's not dreaming
[18:56] <ion_> URL please
[18:57] <Keybuk> lkml
[18:59] <Keybuk> basically it's a backend for dnotify and inotify
[18:59] <Keybuk> but with a new fanotify frontend as well
[18:59] <Keybuk> the new frontend just provides you *all* filesystem events
[18:59] <Keybuk> no need to walk a directory tree to add watches
[19:00] <Keybuk> you can even intercept the access decision in userspace
[19:00] <Keybuk> so can write a virus scanner for example, intercept the open() call
[19:00] <Keybuk> check for viruses
[19:00] <Keybuk> and if you find one, -EPERM it
[19:00] <ScottK> Sounds like Dazuko modules just became obsolete then.
[19:01] <ion_> Neat
[19:01] <ScottK> slangasek: We're closing in on being able to remove libplasma2.  If you could attend to Bug #309420 when you have a moment, that would help.
[19:02] <Keybuk> reading through these, it really sounds like it's exactly what we've needed for ages to do both userspace content checking *and* userspace indexing
[19:05] <emet> how about for 9.04 having a right click option in Nautilus for mounting ISOs by default? :D
[19:13] <Keybuk> cjwatson1: we still don't have selinux udebs, right?
[19:13] <cjwatson> Keybuk: shouldn't need them - udebs shouldn't be built with selinux support
[19:13] <cjwatson> it doesn't really make any sense to have selinux in the installer
[19:14] <Keybuk> that's kinda hard though
[19:14] <slangasek> I thought Manoj had argued for exactly that?
[19:14] <Keybuk> it means you have to, in your package
[19:15] <Keybuk> 1) copy the entire source tree to another directory
[19:15] <Keybuk> 2) rebuild with different options
[19:15] <slangasek> hrm, or use vpath and skip 1) ? :)
[19:16] <cjwatson> everyone else manages :)
[19:16] <Keybuk> ohhh, vpath
[19:16] <Keybuk> forgot about that
[19:31] <bryce> slangasek: do you want a fix for a FBS of -vmmouse?
[19:32] <bryce> slangasek: I think vmmouse will require further work to make it function properly with xserver 1.6, but at least this will enable it to build again.
[19:32] <Keybuk> ugh
[19:32] <Keybuk> the git->bzr thing didn't work out so well
[19:32] <Keybuk> files are missing
[19:36] <smahmood> Hi every1. Can you tell me, where to go, if i'm trying to find help with developing apps for ubuntu?
[19:37] <bryce> smahmood: see topic
[19:38] <smahmood> topic says, that topic is not app-development.. :-)
[19:38] <smahmood> so I'm asking, if you know 'where to go'
[19:41] <LaserJock> smahmood: I think that would depend on the type of app
[19:42] <smahmood> LaserJock: first i would like to make a little desklet-like graphical app, that could perhaps access a MySQL-DB.
[19:44] <LaserJock> smahmood: then perhaps http://live.gnome.org/GnomeIrcChannels might help?
[19:44] <slangasek> bryce: indifferent for alpha-2; we've already kicked it out of -input-all for questions of installability
[19:44] <bbs> two questions
[19:44] <smahmood> LaserJock: yeah, that's good informations. thank you very much.
[19:45] <bbs> 1) how do i pop up a notification service for a daemon in terms of a gui
[19:45] <bbs> similar to growl in os x
[19:45] <smahmood> just one last question....
[19:45] <smahmood> LaserJock: is it helpful, to develop ubuntu first before developing apps for ubuntu?
[19:46] <tjaalton> tseliot, bryce: I tested nvidia-glx-180 and -177. 180 worked with the ignoreABI option, 177 segfaulted
[19:46] <LaserJock> smahmood: they're really 2 different things. you can do both individually
[19:47] <LaserJock> smahmood: if you want to learn how to work on Ubuntu you might want to look at https://wiki.ubuntu.com/UbuntuDevelopment
[19:47] <LaserJock> smahmood: but working on Ubuntu isn't really particularly helpful for you developing an app
[19:48] <LaserJock> smahmood: in fact, you may find out you'd rather just work on Ubuntu and forget that app development stuff ;-)
[19:48] <smahmood> LaserJock: ok, then i'm going to look at developing apps, i think. thank you very much.
[19:49] <LaserJock> no problem
[19:49] <smahmood> :-)
[19:58] <bbs> how do i pop up a dialog box for a .deb for a terms of service agreement or a license agreemen
[19:59] <bbs> t
[19:59] <bbs> i'm using libnotify for the notificaiton i said earlier
[19:59] <bbs> i have no idea how to roll debs
[19:59] <bbs> or how to pop up this required box that points to terms of service and erquires a yes
[19:59] <LaserJock> bbs: https://wiki.ubuntu.com/PackagingGuide and #ubuntu-motu are the places to learn how to create packages
[20:00] <LaserJock> bbs: and usually we use something called debconf for TOS
[20:00] <bbs> for installation
[20:01] <LaserJock> bbs: in particular you could look at something like the sun-java5 package for an example
[20:01] <bbs> ok -- sorry for the stupidity :/
[20:02] <bbs> will this enable a GUI possibility
[20:02] <LaserJock> bbs: it depends on what package manager the user uses mostly, but it's generally text within a GUI
[20:02] <bbs> awesoem for synaptic then
[20:02] <bbs> youg uys are the shit :)
[20:02] <LaserJock> bbs: but it's currently the standard way to do these things
[20:03] <LaserJock> bbs: install sun's java for a view of what it looks like
[20:03] <bbs> LaserJock: i figured that *exact* package would be the place to look :)
[20:03] <bbs> where can i find the specs for these?
[20:03] <bbs> us.archive.ubuntu.org
[20:03] <bbs> err .com
[20:04] <LaserJock> bbs: are you on an Ubuntu machine?
[20:04] <bbs> or do they exists soemwhere else... the specs themselves
[20:04] <bbs> LaserJock: no i run a gentoo derivation
[20:04] <bbs> :/
[20:04] <bbs> i can be
[20:05] <bryce> slangasek: ok that's probably for the best.  I went ahead and uploaded the build fix anyway.
[20:05] <LaserJock> bbs: you can go to https://launchpad.net/ubuntu/jaunty/+source/sun-java6/6-11-0ubuntu1 and grab a couple files
[20:05] <LaserJock> bbs: the full source package is the 3 files (.dsc, .diff.gz, and .orig.tar.gz)
[20:06] <bbs> LaserJock: thanks a lot
[20:06] <LaserJock> bbs: the .orig.tar.gz is upstream tarball, the .diff.gz is a diff that holds all our changes (including all the packaging stuff)
[20:06] <LaserJock> bbs: basically you could on your gentoo machine, untar the .orig.tar.gz and apply the .diff
[20:07] <LaserJock> bbs: you should end up with a source dir with a debian/ dir in it. the debian/ has all the packaging info
[20:07] <bbs> LaserJock: awesoem
[20:07] <bbs> i'll play now
[20:07] <bbs> you have been very helpful
[20:07] <bbs> i really appreciate it
[20:07] <LaserJock> bbs: np, good luck
[20:08] <LaserJock> bbs: if you need more packaging info #ubuntu-motu is a good channel
[20:10] <bbs> ok thx
[20:10] <bbs> i normally only play with src-based
[20:10] <bbs> i appreciate you taking the time
[20:10] <bbs> peace
[20:13] <slangasek> ScottK: lintian, plasmoid-quicklauncher sorted
[20:14] <ScottK> slangasek: Thanks.
[20:50] <tseliot> Keybuk: I tested your patch (for screen-resolution-extra) and it works well
[21:07] <fabbione> kirkland: ping?
[21:07] <kirkland> fabbione: pong
[21:07] <fabbione> kirkland: am I right you maintain mdadm in ubuntu now?
[21:08] <kirkland> fabbione: hmm, not explicitly
[21:08] <kirkland> fabbione: though i've done a fair amount of work in there lately
[21:08] <fabbione> well the changelog is full with your name :)
[21:08] <kirkland> fabbione: themuso has as well :-)
[21:08] <kirkland> fabbione: guilty as charged :-)
[21:08] <fabbione> root@gordian:~# mdadm --assemble /dev/md2 --force /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
[21:08] <fabbione> mdadm: forcing event count in /dev/sdc1(2) from 20491 upto 20502
[21:08] <fabbione> Segmentation fault
[21:08] <fabbione> ^^ good bye 6TB of data
[21:09] <fabbione> now
[21:09] <fabbione> i'd really like to know if that segfault has been fixed
[21:09] <fabbione> this is intrepid
[21:09] <fabbione> (x86)
[21:11] <kirkland> fabbione: hmm, new one on me
[21:11] <kirkland> fabbione: is there a LP bug?
[21:12] <fabbione> no idea.. ask me how much I care with all that data gone? :)
[21:13] <kirkland> fabbione: raid5?
[21:13] <fabbione> yes
[21:14] <kirkland> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499643 ?
[21:14] <kirkland> Severity: grave
[21:16] <fabbione> kirkland: you probably would like to have an SRU in intrepid
[21:17] <kees> fta: I've got an update for flashplugin-nonfree which handles the 64bit plugin, do you want to look at it first, or should I just upload it?
[21:18] <kirkland> fabbione: https://bugs.edge.launchpad.net/ubuntu/+source/mdadm/+bug/282492
[21:19] <kirkland> fabbione: i just linked that against the debian bug tracker, and marked critical
[21:19] <kirkland> fabbione: i need to merge the mdadm package for Jaunty first
[21:19] <Keybuk> cjwatson: do you think I'd be in trouble if I just did the packaging in git? :p
[21:19] <kirkland> fabbione: and then i'll start the SRU process for intrepid
[21:19] <fabbione> kirkland: ok thanks
[21:19] <kirkland> fabbione: you're welcome to subscribe to that bug if you want updates
[21:19] <kirkland> fabbione: thanks for bringing this to my attention
[21:19] <fabbione> kirkland: no. I am happy to see that it's getting attention...
[21:20] <fabbione> kirkland: i have enough spam from LP to even be able to purge the inbox
[21:20] <kirkland> fabbione: yup ... that's the problem with raid.  you don't know something's wrong until the shit really hits the fan :-)
[21:20] <fabbione> kirkland: not really.. a lot can be simulated with loops.. it's easy to make test cases :)
[21:20] <cjwatson> Keybuk: obviously it's a shame when you have to, but you wouldn't be the first. Things ought to change when we have git imports in Launchpad
[21:21] <davmor2> kirkland: you forgot from a great hight
[21:21] <Keybuk> cjwatson: isn't that an "if" we have them?
[21:21] <Keybuk> I'm concious that I've wasted over a day now trying to get this git repository into bzr
[21:22] <Keybuk> git fast-export | git fast-import gives me exactly the same output as input
[21:22] <cjwatson> it's very high up the LP Code priority list
[21:22] <cjwatson> number two I think
[21:22] <Keybuk> git fast-export | bzr fast-import gives me errors, and provided I skip them, a repository that has different files in it!
[21:22] <cjwatson> how about I throw you my random patches?
[21:22] <Keybuk> sure
[21:22] <cjwatson> no guarantee they even apply to current trunk
[21:23] <cjwatson> complete mishmash
[21:23] <cjwatson> but I did do some stuff about directory creation/deletion
[21:24] <Keybuk> sounds plausible
[21:25] <Keybuk> the problems I've been having are when files and directories are deleted or added in the same commit
[21:25] <cjwatson> right, you might get lucky with my changes then; if they help you I'll make an attempt to polish them up for submission
[21:26] <cjwatson> unfortunately it's lumped in with the --file-ids-from stuff I was trying to do as well
[21:26] <cjwatson> which I needed to construct a branch that was merged from another
[21:27] <cjwatson> what did you need to do to get git fast-export to work? earlier you said it was broken
[21:27] <Keybuk> oh, I just deleted the die() and replaced it with a null string :p
[21:27] <Keybuk> "comment out lines of code that don't work"
[21:27] <cjwatson> fun :)
[21:28] <Keybuk> older versions of git didn't record who tagged
[21:28] <Keybuk> git doesn't mind if that field is missing, and apparently bzr doesn't even look for it
[21:28] <cjwatson> can you stick the resulting dump somewhere so that I can have a go at it later?
[21:28] <Keybuk> http://people.ubuntu.com/~scott/udev.git-export.bz2
[21:28] <cjwatson> ta
[21:29] <Keybuk> -        if cmd.ref.startswith('refs/tags/'):
[21:29] <Keybuk> +        if cmd.ref.startswith('refs/tags/') and cmd.from_ is not None:
[21:29] <Keybuk>              self._set_tag(cmd.ref[len('refs/tags/'):], cmd.from_)
[21:29] <Keybuk> yup
[21:29] <Keybuk> made that fix myself ;)
[21:32] <cjwatson> the real reason I hadn't submitted anything yet was that I'd got myself into a state where there was some code I needed to process some commits, but needed to be absent in order to process others
[21:32] <cjwatson> I've forgotten the details just now though ...
[21:46] <ScottK> slangasek: If kde4-style-bespin gets let out of binary New, then with the rebuilds I just uploaded, libplasma2 can be removed.
[21:59] <Keybuk> cjwatson: your patches just move the error :-/
[22:14] <Keybuk> oh, I see..
[22:25] <Keybuk> the directory is empty but a file gets put back in in the same commit
[22:48] <crimsun> slangasek: (RE: pulseaudio recommending paprefs) if suggests are not installed automatically, paprefs could be demoted; otherwise, it seems reasonable to drop it in the short run
[22:49] <slangasek> yes, by definition Suggests are not to be installed automatically
[22:51] <crimsun> slangasek: right, in that case just demoting paprefs to Suggests seems the way to go
[22:52] <slangasek> spiff
[23:02] <homunq> OK sorry to bother you here but I need expert help and I'm only going to ask this once. Please respond in pm if you can help me, I don't want to clog here. I am stuck in this konversation window. Can type and click here, can get to text-mode terminal, but can't switch windows. Seen this bug feisty, hardy, intrepid; kubuntu, xubuntu, ubuntu. Right now I'm in xubuntu (xfce). Looking for help using the terminal to diagnose. One person suggested it could
[23:02] <homunq> be stuck keys, best theory so far.
[23:24] <slangasek> kirkland, soren, mathiaz: is there any automated testing of server ISOs these days? (jaunty alpha-2 candidates have been up for a while)
[23:25] <soren> slangasek: No :(
[23:25] <slangasek> oh
[23:26] <slangasek> could someone do a manual test of something, so I can bless the ISOs for alpha-2? :)
[23:27] <soren> I'm in no condition to do testing.
[23:27] <directhex> slangasek, how's the disk consumption?
[23:27] <soren> I'd sign off on all sorts of stuff at this point.
[23:27] <soren> :)
[23:27] <kirkland> slangasek: i suppose i can, assuming testing in a kvm is okay
[23:27] <kirkland> slangasek: mathiaz tends to handle this, but he's out on vaca
[23:27] <slangasek> kirkland: kvm is perfectly fine
[23:28] <slangasek> directhex: disks are all right-sized now; dropping the fortran deps from python-numpy was a big help
[23:28] <kirkland> slangasek: http://cdimage.ubuntu.com/releases/jaunty/ ?
[23:29] <slangasek> directhex: I think there's some more mono 1.0 stuff that could we could dispense with, but it's no longer urgent
[23:29] <directhex> slangasek, well, yes, i can imagine
[23:29] <slangasek> kirkland: http://iso.qa.ubuntu.com/qatracker/test/2194 , http://iso.qa.ubuntu.com/qatracker/test/2195
[23:31] <directhex> slangasek, we'll continue to make improvements as time passes. meebey has a plan to save another good 2.5 meg from the main mono stack, but that one means the agony of NEW again
[23:31] <directhex> slangasek, for now, i'm glad that alpha 2 seems to have come together reasonably well
[23:32] <kirkland> slangasek: but the iso, is just the current builds at http://cdimage.ubuntu.com/ubuntu-server/daily/current/ ?
[23:33] <slangasek> kirkland: that happens to be correct; I gave the direct links because sometimes it's the case that there's a newer ISO build than the one we're trying to test for an alpha
[23:33] <kirkland> slangasek: pooh ... i *just* deleted those iso's
[23:33] <kirkland> slangasek: i thought there was something newer than that :-P
[23:34] <slangasek> no, they've been sitting untested for >24h :)
[23:35] <kirkland> slangasek: well, unofficially, i did install from them this morning
[23:35] <kirkland> slangasek: no record in isoqa, though
[23:35] <slangasek> oh.  record it now? :)
[23:37] <slangasek> fwiw, we're also still in need of testing of ubuntu desktop images, at least; I'm not sure I'm going to be able to get a useful test here, since I only have vmware available for v12n and vmmouse is DOA :)
[23:47] <slangasek> directhex: btw, gnome-sharp2 had to go through NEW itself for a naming transition given the packages I pulled from experimental, I'm not sure what the transition plan for those needs to look like
[23:48] <directhex> slangasek, i think slomo's the last one who poked those, so i don't know the full story
[23:48] <slangasek> ok
[23:48] <slangasek> I guess tomboy/f-spot mainly just need build-deps updated and then rebuilt, but I haven't tested yet
[23:51] <directhex> slangasek, if the space concern for alpha2 is gone, i'd let things carry on as-is. we'll get onto those within pkg-mono ASAP, but ASAP doesn't necessarily mean "tonight" ;)