[12:26] <sits> hi?
[12:27] <sits> Do any of the kernel folks know of a problem with intel SATA in the latest Ubuntu kernel?
[12:27] <sits> ata_piix / ICH4&ICH5 boards
[12:28] <sits> Bug #116996
[12:28] <ubotu> Launchpad bug 116996 in linux-source-2.6.20 "sata disk in ide mode with kernel 2.6.20-16-generic (ata_piix broken?)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116996
[01:09] <abo> sacater, hi again
[01:10] <sacater> abo: hi
[01:10] <sacater> abo: tell these nice people whats happened
[01:10] <abo> ok 
[01:11] <abo> hi all... after upgrading to the latest kernel, my camera isn't automounting when plugged, booting into the previous kernel fixed the problem
[01:12] <abo> after upgrading the kernel ...  my camera isn't automounting when plugged, booting into the previous kernel fixed the problem
[01:12] <abo> do you need any more info?
[01:15] <pochu> abo: please, file a bug. This channel isn't for support :)
[01:15] <abo> pochu, sacater asked me to report what happened here.. for me i'm fine now my camera is working, thx
[01:16] <sacater> pochu: eep
[01:16] <pochu> abo: is that Feisty?
[01:16] <abo> yes
[01:17] <pochu> Then https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+filebug is the link.
[03:43] <TheMuso> C
[03:43] <TheMuso> ugh typing
[03:50] <BTZ> I've been looking for a package that provides kernel development manpages without much success. Is there such a thing in feisty?
[03:52] <johanbr> BTZ: linux-doc-2.6.20 has some kernel docs.
[03:55] <BTZ> johanbr: I noticed some linux distros have manpages for stuff like cdev_init, printk, kmalloc, etc. linux-doc-2.6.20 does not seem to provide them.
[03:55] <Hobbsee> oops.  now, if i'm going to leave my computer on while sleeping, i really should plug it in...
[04:05] <johanbr> BTZ: Those don't seem to be in ubuntu, no.
[05:22] <hile> siretart: sent you mail about cryptsetup changes. While the new udevsettle patch is not my patch, it does it's job (and is cleaner), thank you very much
[05:23] <hile> still think we should get rid of activate_evms and activate_lvm, those are done by udev now, but if we share package with debian, it might be debian's ramdisk still needs those...
[05:24] <hile> at least 'activate_lvm' is bogus which I can confirm (have been running modified initramfs without it for months, with encrypted LVM setup)
[05:24] <hile> and I see no reason why the evms part would be any less bogus, if udev handles evms as well
[05:26] <hile> still, booting to 2.6.22-15 with encrypted root on LVM fails, but this is not related to my earlier errors, it seems to be a crypto module loading issue
[05:27] <hile> happened with edgy as well, iirc, crypto modules were just renamed ... 
[05:46] <Burgundavia> nixternal: https://wiki.ubuntu.com/WriteYourRepresentative
[05:46] <nixternal> heh
[05:46] <nixternal> you are a couple of channels off
[05:46] <Burgundavia> indeed, I am
[05:46] <nixternal> lol
[05:48] <Hobbsee> siretart: ping
[05:49] <Hobbsee> siretart: sorry, bad ping
[05:54] <reitblatt> ping kylem: ok to go ahead and confirm bug #87262 ?
[05:54] <ubotu> Launchpad bug 87262 in linux-source-2.6.20 "Virtual PC and feisty fawn" [Undecided,Needs info]  https://launchpad.net/bugs/87262
[05:54] <reitblatt> you're still assigned on it, so I don't want to step on your toes
[06:07] <calc> Hobbsee: hi
[06:08] <calc> still no word on my condo loan closing :\
[06:08] <Hobbsee> hey calc!
[06:08] <Hobbsee> aww
[06:09] <Hobbsee> heh
[06:09] <calc> i have to be totally moved out of my apt tomorrow, so i had to move in with my gf's parents until i can move into the condo
[06:09] <Hobbsee> they wont do what you want, if you do that :P
[06:09] <Hobbsee> urgh
[06:17] <calc> heh
[06:17] <ccm> good morning *moan*
[06:19] <ion_> Good night.
[06:36] <poningru> going to sleep
[06:36] <poningru> err sorry worng channel
[07:49] <siretart> hile: I agree that we really need to discuss this with the debian cryptsetup maintainers. 
[08:25] <Mithrandir> pitti: any chance you could review sexy-python for main, so we can get -desktop installable?
[08:25] <pitti> Mithrandir: sure, will do right now
[08:25] <Mithrandir> thanks.
[08:31] <pitti> Mithrandir: promoted
[08:31] <Mithrandir> cheers.
[08:54] <hile> siretart, anyway thanks for finally fixing the device waiting issue - does feisty have exactly same udevsettle commands? I think we could add the same udevsettle line there 
[08:55] <hile> this other laptop where I'm writing from has feisty and LVM encryption, I can easily test adding the udevsettle line to unmodified hook script there
[09:02] <hile> oh, udevsettle _is_ there, what have I missed...
[09:21] <Mithrandir> mmm, removals.
[09:21] <doko> pitti, Mithrandir: m2crypto, python-fuse, orsa aren't synced (-buildN version number)
[09:21] <pitti> doko: they will on the next autosync run
[09:21] <pitti> Mithrandir: cruft-check?
[09:21] <Mithrandir> yeah
[09:21] <Mithrandir> and I'm not really done with it either.
[09:21] <Mithrandir> and I skipped those with scary rdeps lists
[09:22] <Mithrandir> like, libsnmp9
[09:22] <Mithrandir> pitti: I ran autosync this morning, so it should be good now.
[09:22] <siretart> hile: we can provide updated (testing) deps in a PPA (personal package archive)
[09:25] <hile> well, actually feisty default package already works, last revision (cryptsetup 2:1.0.4+svn26-1ubuntu2) fixed this
[09:25] <hile> I just did not notice it ... and had my own pkgs overriding 
[09:26] <siretart> oh, even better. so we don't even need to do anything for feisty :)
[09:26] <hile> I can confirm  encrypted LVM PV under root fs problems are solved!
[09:26] <pitti> thekorn: hello
[09:26] <siretart> hile: you've written me about a README?
[09:27] <hile> yeah, it was with the big patch, but you can get it from http://ner.dy.fi/deb/cryptsetup/feisty/README.patch
[09:27] <thekorn> hi pitti
[09:27] <pitti> thekorn: is it planned to add a python-launchpad-bugs API for deleting attachments? that's really important for the apport stuff
[09:28] <thekorn> pitti: I think it's not planned yet,
[09:29] <thekorn> but i'm happy adding it to my TODO list,
[09:29] <thekorn> should not be so difficult
[09:29] <pitti> thekorn: no, it's just another 'emulate clicks' thingy; the most difficult thing is to bolt it into the API in a consistent way
[09:30] <pitti> thekorn: and I don't know what the current plan for API redesign is
[09:30] <thekorn> pitti: my plan is to start working on the redesign this week,
[09:31] <thekorn> so adding this won't be a problem
[09:31] <hile> siretart: the text maybe should go to CryptoRoot.HowTo, I'm not really sure ... whatever
[09:32] <siretart> hile: I've committed your patch to README as revision 11, which will appear soon at https://code.launchpad.net/~siretart/cryptsetup/ubuntu
[09:32] <hile> ok, thanks
[09:32] <pitti> thekorn: ah, nice; I'm happy to participate in the design discussion
[09:32] <siretart> hile: feel free to work further on the READMEs. they are welcome!
[09:33] <hile> yep
[09:33] <siretart> hile: however, perhaps we should start a separate file, and not use the existing files from debian to make merging easier
[09:35] <hile> hmm I started thinking, does partman-crypto already support encrypted LVM ... it would be quite trivial for it to setup after all
[09:35] <dholbach> good morning
[09:35] <hile> well, have to write documentation for new servers ->
[09:35] <dholbach> pitti: somehow my texlive-bin fix does not fix the evince ftbfs (it builds normally, but not in pbuilder) - could it be that libkpathsea-dev should depend on libkpathsea4?
[09:38] <pitti> dholbach: oh, indeed, it doesn't; yes, of course it needs to, to resolve the /usr/lib/libkpathsea.so symlink
[09:38] <doko> Riddell (or another kubuntu guy): could you sync/merge wlassistant from universe-manual ?
[09:38] <dholbach> pitti: ok, I'll do another upload and test if that fixes it
[09:38] <dholbach> hey doko
[09:40] <doko> dholbach: hey!
[09:41] <dholbach> doko: how's it going? how is your hand/arm?
[09:43] <dholbach> doko: did you consider using workrave?
[09:43] <pitti> bdmurray: would you have some time to verify bug #113508, so that we can push it to -updates and silence feisty crashes?
[09:43] <ubotu> Launchpad bug 113508 in adept "adept notifier still notifies kubuntu users of apport crashes" [High,Fix committed]  https://launchpad.net/bugs/113508
[09:43] <doko> dholbach: still splinted
[09:44] <siretart> hile: yes, we need to test and adapt partman-crypto for gutsy. 
[09:44] <doko> dholbach: for rowing?
[09:44] <dholbach> doko: oh, so you reckon it was caused by rowing and not by typing 24h a day? :)
[09:45] <pitti> ooooh, FFS, I suck
[09:46] <pitti> somewhere in ddeb-retriever's version domination there's a bug, so that feisty ddebs got killed
[09:47] <pitti> no wonder that so many retraced bugs have failed stack traces
[09:48] <pitti> s/failed/unusable/
[09:48] <dholbach> happy HUG DAY!
[09:59] <pitti> hi seb128
[10:00] <seb128> hey pitti
[10:00] <cjwatson> Spads: thanks; I'm adjusting various small things for that now.
[10:00] <cjwatson> (powerpc on ports)
[10:00] <dholbach> good morning cjwatson
[10:02] <cjwatson> keescook: I can't claim to understand the patch, but I'm happy for it to be given a try in gutsy
[10:02] <cjwatson> morning
[10:27] <cjwatson> ok, who ate base-files' Priority field?
[10:28] <pitti> cjwatson: yesterday we noticed that since the latest Soyuz rollout there are no Priority fields any more; this also makes all packages in MoM red
[10:28] <cjwatson> yes, override.gutsy.main is blank
[10:28] <cjwatson> this buggers up the installer very comprehensively
[10:29] <cjwatson> has anyone raised this with the soyuz team? it's critical
[10:29] <cjwatson> I really hope the data has not disappeared from the db
[10:30] <cjwatson> ok, it does seem to still be therre
[10:30] <cjwatson> there
[10:44] <cjwatson> pitti: not all Priority fields, though, only some
[10:45] <cjwatson> lp_archive@drescher:~$ zcat ubuntu/dists/gutsy/main/binary-i386/Packages.gz | grep-dctrl -P -nsPackage -r . | wc -l
[10:45] <cjwatson> 5380
[10:45] <cjwatson> lp_archive@drescher:~$ zcat ubuntu/dists/gutsy/main/binary-i386/Packages.gz | grep-dctrl -FPriority -nsPackage -r . | wc -l
[10:45] <cjwatson> 3623
[10:51] <seb128> siretart: bug #117703, any reason we don't sync emacs22?
[10:51] <ubotu> Launchpad bug 117703 in emacs-snapshot "please sync emacs-snapshot from http://emacs.orebokech.com/" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117703
[10:52] <siretart> seb128: as explained in the bug, it is in experimental for a reason
[10:52] <siretart> seb128: maintainer has indicated that he wants to do further changes with impact before uploading to unstable
[10:52] <seb128> k
[10:52] <seb128> you didn't indicate the reason
[10:52] <siretart> seb128: romain's packages are more similar to what we already have
[10:52] <siretart> I didn't?
[10:52] <seb128> "(there is on in experimental, but for a reason)"
[10:53] <siretart> ah, sorry
[10:53] <seb128> no problem ;)
[10:55] <siretart> seb128: one obvious benefit of romain's packages: they come with documentation
[10:55] <siretart> and emacs without documentation is nearly useless :/
[10:57] <seb128> Lure: could you get the sync request on bug #117153 validated by a MOTU?
[10:57] <ubotu> Launchpad bug 117153 in strigiapplet "sync strigiapplet 0.5.1-1 from debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117153
[10:57] <Lure> seb128: I am MOTU ;-)
[10:57] <seb128> Lure: not according to https://launchpad.net/~lure/
[10:58] <seb128> gra, the page is confusing
[10:58] <seb128> it doesn't list all the team
[10:58] <seb128> that's alright ;)
[10:58] <Lure> seb128: yep, I was confused a couple of times too ;-)
[11:13] <pitti> seb128: ah, too bad; I asked Debian to add the Conflicts: libpoppler1-qt4 to libpoppler-qt4-1, but they didn't; so we cannot sync just because of this
[11:17] <StevenK> seb128: Should I be able to see the libkexiv2 sync you processed an hour ago in LP?
[11:18] <StevenK> (Since I can't)
[11:18] <seb128> StevenK: no, I just run the command to process the syncs now
[11:18] <seb128> we batch them
[11:18] <seb128> s/run/ran
[11:19] <StevenK> Ah, right.
[11:22] <siretart> seb128: do I need to monitor romains emacs-snapshot packages manually, or will they get autosynced?
[11:22] <seb128> siretart: monitor
[11:22] <siretart> k
[11:24] <doko> seb128: nothing else to do so that you can process sync requests with lightning speed ... ;-P
[11:24] <seb128> doko: I was doing sync but every time I refresh the page to look if I'm done with them there is a new bug from you :p
[11:25] <seb128> doko: looks like python-dbg changes are going to Debian, that good ;)
[11:25] <seb128> doko: is that a Debian announce mail or somebody that we could point if we send a patch to Debian?
[11:26] <doko> seb128: on my list ...
[11:26] <seb128> k
[12:34] <seb128> crimsun: do you get that rhythmbox crash when ejecting and ipod on gutsy?
[12:45] <mdz> Mithrandir: you mean it works for you sometimes?
[12:50] <dholbach> Mithrandir: is that on gutsy or on feisty?
[12:51] <dholbach> Mithrandir: for gutsy siti started taking care of opal+pwlib+ekiga and we're closer to upstream again (finally) - so it'd make sense to report a bug and forward it upstream
[12:53] <dholbach> awesome! - I announced http://lists.ubuntu.com/mailman/listinfo/ubuntu-motu-mentors an hour ago and we already have 24 subscribers
[12:54] <pitti> dholbach: nice that there's so much interest
[12:54] <dholbach> expect more ubuntu-dev members soon :-D
[12:55] <dholbach> if you need help with bugs you marked as 'mentoring available' you could post a link on that list
[12:56] <ccm> what i am a bit puzzled about is that there seems to be no easy way to mark bugs as belonging to a specific ubuntu version or am i wront?
[12:57] <ccm> erm wrong
[12:57] <dholbach> ccm: usually we fix bugs in the current development version
[12:58] <ccm> dholbach: well there are currently dapper (lts), edgy, feisty and gutsy to keep in launchpad, am i wrong?
[12:58] <ccm> all of them ar either supported or in development process
[12:58] <dholbach> ccm: using "target to release" on the left hand side can be used to nominate a fix for a backport
[12:59] <dholbach> ccm: yes, but we only backport fixes that fall under a certain category: http://wiki.ubuntu.com/StableReleaseUpdates
[12:59] <ccm> dholbach: okay, i will read that, thank you
[12:59] <dholbach> anytime
[01:03] <cyber> hello everybody
[01:21] <Mithrandir> dholbach: opal broke the ABI without bumping the soname, so yes.
[01:21] <Mithrandir> dholbach: and gutsy, yes.
[01:21] <Mithrandir> mdz: yes, it usually works for me.  Doesn't it for you?
[01:22] <dholbach> Mithrandir: grngrngrngrn :-(
[01:22] <mdz> Mithrandir: no :-/
[01:22] <Mithrandir> mdz: consistently, or just in gutsy?
[01:22] <Mithrandir> ekiga: symbol lookup error: ekiga: undefined symbol: _ZN11SIPEndPoint8RegisterERK7PStringS2_S2_S2_S2_i
[01:22] <Mithrandir> downgrading libopal-2.2.0 to the feisty version fixed it.
[01:24] <mdz> Mithrandir: typically
[01:24] <mdz> not as in "doesn't run", but that I'm not able to successfully make/receive calls
[01:24] <Mithrandir> ugh, ok.  I'm using my own asterisk setup, unsure if that's relevant or not
[01:27] <Mithrandir> dholbach: do you want a bug about it?
[01:27] <dholbach> Mithrandir: that'd be nice - I'm not taking care of ekiga and friends any more, but I sponsor siti's uploads (I hope we'll have a ubuntu-voip team soon)
[01:29] <Mithrandir> ook
[01:50] <agoliveira> Mithrandir: Hi. Did seb128 send that patch for hildon-fm?
[01:51] <seb128> agoliveira: you mean "upload gtk+ patched"? not yet, I'm working on it right now
[01:51] <seb128> why?
[01:54] <agoliveira> seb128: Well, because it would help us go ahead with the hildon components :)
[01:54] <Mithrandir> agoliveira: you can just apply it locally and build a local gtk+
[01:55] <seb128> agoliveira: I know, I'm on it, will be uploaded soon
[01:55] <agoliveira> Mithrandir: Am I missing anything? I tought it was not avaliable yet.
[01:55] <agoliveira> seb128: Thanks.
[01:57] <seb128> agoliveira: the patch has been sent on the list
[01:58] <agoliveira> seb128: Ah, sure. Sorry I misunderstood it.
[02:25] <Riddell> StevenK: ping, are you working on main-manual merges?
[02:26] <StevenK> Riddell: I have been.
[02:27] <StevenK> Riddell: libkexiv2, libmtp and scim-qtimm are dealt with. I was just about to pick another.
[02:27] <Riddell> StevenK: ok great, thanks.  I'm through my e-mail backlog now so let me know what you pick and I'll go with the other one
[02:28] <StevenK> Riddell: Of yours, only ksystemlog and knetworkmanager are left. Hobbsee said to not touch knetworkmanager, which leaves only ksystemlog. Do you want to do it?
[02:29] <Riddell> StevenK: you go ahead, I'll move on to http://merges.ubuntu.com/universe-manual.html
[02:29] <StevenK> Riddell: Great, thanks.
[02:32] <maswan> kylem: Having worked alot on this, we can't seem to reliably trigger anything other than a tendancy to get more frequent and severe page-allocation failures in .55 than .53. The lockups etc seems to be not reproducable. :/ Any suggestions, or should we just cancel it as a false alarm?
[02:54] <Hobbsee> evening all
[02:55] <highvoltage> hi Hobbsee 
[02:56] <Hobbsee> heya highvoltage :)
[03:00] <siretart> has anyone seen pitti lately?
[03:00] <seb128> siretart: he's away for lunch
[03:01] <siretart> ah, ok
[03:01] <Hobbsee> siretart: i ate him.  i was hungry.
[03:02] <StevenK> "SCREEM is a tag-based Web page editor ..."
[03:03] <StevenK> So it seems siretart is going to write a web page using screem.
[03:04] <siretart> screaming, even,
[03:04] <Hobbsee> :P
[03:05] <cjwatson> debootstrapping gutsy works again, for those who noted that it was broken
[03:05] <StevenK> Yay!
[03:06] <Hobbsee> woo!  people in #ubuntu+1 were whining about it for the last couple of days
[03:06] <cjwatson> it was a soyuz bug
[03:06] <siretart> the bug about lost priorities?
[03:06] <cjwatson> yes
[03:07] <cjwatson> when base-files isn't spotted as being Priority: required, you have no /proc ...
[03:07] <StevenK> Oh, neat.
[03:07] <Hobbsee> very neat
[03:13] <cjwatson> dholbach: were you working on https://launchpad.net/+builds/+build/340909 ?
[03:13] <cjwatson> (evince build failure)
[03:14] <dholbach> yes
[03:14] <dholbach> I uploaded evince - it should build now - I just submitted the fix to Debian too
[03:15] <cjwatson> ah yes, it's in accepted, thanks
[03:16] <dholbach> np
[03:18] <StevenK> Hobbsee: Set your keymap to Dvorak. That ought to help, or something.
[03:18] <Hobbsee> StevenK: heh.  or just unbandage my finger, if i'm not going to bleed everywhere again.  either would work.
[03:22] <thom> fsvo help
[03:22] <Hobbsee> thom: ?
[03:23] <thom> i'm somewhat sceptical that dvorak would be a short term help, per mr kowalik's suggestion :-)
[03:23] <Hobbsee> ahh
[03:24] <Hobbsee> @schedule sydney
[03:24] <ubotu> Schedule for Australia/Sydney: Current meeting: Edubuntu | 31 May 06:00: Xubuntu Developers | 01 Jun 02:00: Ubuntu Development Team | 01 Jun 07:00: Kubuntu Developers | 06 Jun 05:00: Technical Board | 07 Jun 06:00: Edubuntu
[03:24] <Hobbsee> oof.
[03:25] <Hobbsee> 5am
[03:32] <kylem> maswan, it's probably worth an email to andrew morton about (in the general sense, not for ubuntu help)
[03:32] <maswan> kylem: yeah, I'll respond to the bug and suggest closing it. it does not seem to be a regression, just that we triggered it just after upgrading.
[03:33] <kylem> it shouldn't really fall over like that one way or another.
[03:35] <maswan> Yeah, it shouldn't. But it isn't (much, .55 seems to get page-allocation failures quicker/more than .53) related to that particular upgrade though.
[03:36] <Hobbsee> siretart: he's found.
[03:37] <siretart> Hobbsee: thanks. 
[03:37] <Hobbsee> :)
[03:37] <siretart> pitti: I need to bug you in a few hours ;)
[03:37] <pitti> hey siretart, what's up?
[03:37] <siretart> oh, it's about ffmpeg
[03:40] <iwj> pitti: FAOD I'm about to do the dpkg merge as promised.
[03:40] <pitti> iwj: ah, thanks
[03:41] <iwj> Oh.  It looks like I may need some magic merge script of Colin's.
[03:41] <iwj> Most of the clashes are in .gmos.
[03:41] <iwj> #include <i18nrant.h>
[03:42] <cjwatson> drop .gmos, they're binary and generated (and shouldn't really be in source packages IMHO)
[03:42] <pitti> iwj: hm, in general we drop all the .po/.gmo changes relative to Debian, but since dpkg is blacklisted from stripping, it's a bit special
[03:42] <pitti> iwj: the question is why they are in the orig.tar.gz in the first place
[03:42] <pitti> right, what colin said
[03:43] <cjwatson> .po --msgfmt--> .gmo
[03:45] <iwj> cjwatson: OK.
[03:45] <maswan> kylem: it would have been convenient with an lts-supported ubuntu with an 2.6.20 or newer too. ;)
[03:46] <iwj> There's some .po's too but I can probably merge those by hand.  Let me look at how bad they actually are.
[03:46] <Mithrandir> maswan: the plan is for gutsy+1 to be LTS
[03:47] <bhale> that is a year away
[03:47] <Mithrandir> it is
[03:47] <maswan> Mithrandir: Yeah, I know. 
[03:47] <StevenK> Mithrandir: And have the longer release cycle, or is that undecided?
[03:48] <StevenK> Hey! It's cold enough without you helping.
[03:49] <Mithrandir> StevenK: gutsy is having a slightly shorter one and gutsy+1 will have a slightly longer one.
[03:49] <Mithrandir> less than the six weeks we had for dapper, but a couple of weeks at least.
[03:49] <bhale> Hobbsee: ?
[03:49] <bhale> Hobbsee: hugs.
[03:49] <Hobbsee> bhale: heya
[03:49] <Hobbsee> bhale: isnt throwing icecubes a greeting?
[03:50] <pitti> iwj:out of interest, which parts of dpkg did we touch, string-wise?
[03:50] <StevenK> Mithrandir: How much was taken from Gutsy? I didn't notice the release being shorter.
[03:50] <cjwatson> last I checked the dpkg string diff was Breaks
[03:51] <Mithrandir> StevenK: just a week, I think.
[03:51] <StevenK> Ah
[03:51] <Mithrandir> StevenK: since the original plan would have put it back-to-back with UDS which would have been utter insanity.
[03:52] <StevenK> Especially for the distro team...
[03:52] <StevenK> I wonder if that makes Gutsy+1 the first odd numbered release.
[03:53] <StevenK> Adding a few weeks presumably takes it from April to May.
[03:53] <Mithrandir> yes, and the "what if something goes a bit wrong".  Having the whole distro team jump on a plane the day after release is.. not wise.
[03:53] <StevenK> Ah, that's a point.
[03:57] <Hobbsee> meh.  depends how long the plane flight is
[03:57] <Hobbsee> and if there's wifi
[04:01] <Lure> any archive-admin on duty today: would need strigi through binary NEW to be able to make strigiapplet build
[04:01] <Hobbsee> pitti: ^
[04:01] <pitti> ... and gets a segfault
[04:02] <Hobbsee> haha
[04:02] <StevenK> Heh
[04:02] <pitti> Hobbsee: ok
[04:02] <pitti> Hobbsee: that helped, seb128 is back :)
[04:02] <Hobbsee> pitti: ahh, now you can delegate
[04:02] <StevenK> Oh look, the pointer is no longer NULL
[04:02] <seb128> Mithrandir: k, I've GTK+ ready to upload now, do you have an opinion on shlibs update or not?
[04:03] <Lure> seb128: [16:01]  <Lure> any archive-admin on duty today: would need strigi through binary NEW to be able to make strigiapplet build
[04:03] <Lure> seb128: [16:01]  * pitti points to seb128
[04:03] <Lure> ;-)
[04:03] <seb128> k, will look at it next
[04:03] <Lure> seb128: thanks
[04:05] <pitti> seb128: due to a limitation of ddeb-retriever and silly me not flipping it to gutsy early enough we lost some ddebs of feisty, in particular libc6
[04:05] <pitti> seb128: that would explain why so many feisty crash retraces are broken
[04:05] <seb128> oh
[04:05] <pitti> just FYI
[04:06] <seb128> I didn't notice since we got almost no desktop crashers since we stopped apport
[04:06] <seb128> but good to know ;)
[04:06] <pitti> I sat down today (and am still sitting) to fix this once and for all
[04:07] <seb128> no
[04:07] <seb128> there is no real reason to use edgy rather than feisty
[04:07] <seb128> I expect most of users have upgraded
[04:08] <seb128> we get an edgy bug every now and then, no need to keep the whole ddeb set only for those imho
[04:08] <pitti> also, no auto-retracing magic and such
[04:09] <seb128> right
[04:10] <seb128> Lure: any reason to have "libcluceneindex.so -> libcluceneindex.so.0" rather than to the real lib (libcluceneindex.so.0.5.1)?
[04:11] <Lure> seb128: I do not soo good reason for it, but should talk with debian about it
[04:11] <Lure> s/soo/see/
[04:13] <seb128> Lure: strigi NEWed
[04:13] <Lure> seb128: thanks
[04:13] <seb128> np
[04:14] <seb128> Mithrandir: I've not changed the GTK+ shlibs (I don't want to increase the requirement from 2.10.3 to 2.10.12 only for this hildon function) you will need to force the hildon-fm Depends version, let me know if you disagree
[04:18] <sits> hi I'm having issues with ubquity on Feisty
[04:18] <sits> When I tell it to do a guided install it gets as far as setting up an ext3 partition
[04:19] <sits> it then seems to get confused and redetects an old ntfs partition
[04:19] <sits> which halts the install
[04:19] <sits> (and goes on to prevent sfdisk -R /dev/sda from working)
[04:19] <sits> I have the machine available for testing now
[04:20] <sits> but if no one's interesting then I think I will just dd zero the start of the partition and forget about the problem...
[04:20] <sits> s/interesting/interested
[04:20] <Hobbsee> cjwatson: ^
[04:20] <sits> I can post logs and what not now
[04:21] <sits> and I'm willing to reboot and reproduce the problem a few times before giving up completely
[04:21] <sits> Hobbsee: ah ok how do I get hold of cjwatso?
[04:21] <cjwatson> sits: I'm here
[04:21] <sits> cjwatson: oh hi
[04:21] <cjwatson> sits: could you put /var/log/syslog and /var/log/partman somewhere?
[04:21] <sits> cjwatson: ok bear with me
[04:21] <cjwatson> not pasted into channel :)
[04:22] <sits> ;)
[04:22] <heno> mdz: you are down as approver for https://blueprints.launchpad.net/ubuntu/+spec/installer-for-windows Can you have a look today or tomorrow?
[04:22] <mdz> heno: yes, will do
[04:23] <sits> cjwatson: http://cs.swan.ac.uk/~cssits/ub/
[04:23] <mdz> heno: I was just looking for you; do you have time for a phone call today?
[04:23] <heno> mdz: yes, and thanks
[04:23] <sits> cjwatson: if this proves too cumbersome I can probably arrange for you to ssh into the machine directly (since it's all running off a livecd)
[04:24] <iwj> Oh FFS they've REORGANISED THE DIRECTORY STRUCTURE.  Why oh why oh why etc.
[04:24] <mdz> heno: how about at 1500 UTC (about 30 minutes from now)
[04:26] <cjwatson> sits: I'll be a moment - helping somebody else at the same time
[04:27] <sits> ok
[04:28] <heno> mdz: sounds good
[04:31] <Mithrandir> seb128: that's fine with me; thanks a lot.
[04:32] <seb128> Mithrandir: you're welcome
[04:33] <cjwatson> sits: just so I'm certain, which particular flavour of guided partitioning did you select?
[04:34] <sits> cjwatson: er the top one (i.e. the automatic guided I think)
[04:35] <cjwatson> which one is the top one varies depending on what's on the disk
[04:35] <sits> cjwatson: bear with me
[04:35] <cjwatson> it might be resize some partition and use freed space, or it might be use a whole disk
[04:36] <sits> cjwatson:  Guided - use entire disk
[04:36] <sits> cjwatson: partition table was blanked beforehand with fdisk /dev/sda
[04:36] <sits> o
[04:41] <sits> cjwatson: any clues?
[04:41] <iwj> cjwatson: They've reorganised the .po files in dpkg into one .po per language rather than one per (language,manpage).  Do you have a magic tool that will help with this merge or shall I just concatenate the files before diffing and fix it up by hand ?
[04:42] <bryce> heya glatzor
[04:42] <glatzor> hello bryce
[04:43] <cjwatson> sits: something very weird is going on; I'm trying to work it out
[04:44] <cjwatson> iwj: sounds like a sensible reorganisation. I'd try to find out what they used to do the job and mirror it; they probably used some combination of msgcat and/or msgmerge
[04:44] <cjwatson> iwj: do we actually have any translations of the Ubuntu-specific strings?
[04:44] <cjwatson> iwj: if not, you could just drop everything but the .pot ...
[04:44] <cjwatson> or in fact drop that too and just regenerate it
[04:45] <Mithrandir> looking at the ubuntu patch and trying to apply that hunk by hunk might work
[04:45] <sits> cjwatson: I thought it might be worth investigating : )
[04:45] <sits> cjwatson:  I have a feeling it might be kernel related because after the error occurs sfdisk -R /dev/sda stops working
[04:45] <cjwatson> Mithrandir: I'm not sure that wouldn't just be unnecessary work in this case
[04:46] <sits> even when I unmount all partitions on that disk
[04:46] <cjwatson> sits: I'm reserving judgement for now
[04:47] <sits> cjwatson: ah ok I'll shut up and let you look before spouting off...
[04:49] <cjwatson> iwj: (thinking out loud) I'm starting by getting a more intelligent diff, by running msgcat over some of the allegedly changed .po files on the Debian side first
[04:49] <cjwatson> a lot of the hu.po diffs seem to be essentially spurious
[04:49] <cjwatson> msgcat turns a .po file into canonical form as far as line-wrapping is concerned
[05:00] <iwj> cjwatson: Hmm.  I'll investigate.  Thanks.
[05:00] <glatzor> bryce: I had some ideas during today's train ride.
[05:01] <cjwatson> iwj: ok, I've confirmed that the .po diffs contain no actual translations
[05:01] <bryce> glatzor: cool.  
[05:01] <glatzor> bryce: for the unit testing it could be enough to feed displayconfig backend with the xorg.conf and the pcitable, apply the changes and then compare it to the correct xorg.conf?
[05:02] <bryce> glatzor: I spent some time testing it last evening.  I sent in some bug reports for issues I found testing on nvidia and on a dual-screen system
[05:02] <cjwatson> iwj: I did this by using msgcat to get rid of a bunch of the line-wrapping diffs, eyeballing the result, and also checking with things like "for x in man/po4a/dpkg.1/po/*.po; do msggrep -K -F -e 'B<breaks>' $x | msgattrib --translated --no-fuzzy; done" for each added string and manual page
[05:02] <bryce> glatzor: yup
[05:02] <cjwatson> iwj: so my advice would be to throw away the .po file diffs and let whatever it is regenerate them
[05:02] <iwj> OK :-).
[05:02] <bryce> glatzor: that's a very good, traditional approach for unit tests
[05:02] <glatzor> bryce: this should be doable :)
[05:02] <iwj> cjwatson: Thanks muchly.
[05:02] <bryce> glatzor: :-)
[05:03] <bryce> glatzor: also I had a question - how do I get the pci tables?
[05:04] <bryce> I loaded the latest version from bzr (I think), but didn't see anything that suggested pci table capturing
[05:04] <glatzor> bryce: you should update the bzr branch and then run ./displayconfig-gtk --data-dir=data --w FILENAME
[05:04] <sits> cjwatson: ok I need to shut the machine down because I need to use the install disk to reimage another machine. If there's anything you need pronto let me in the next five minutes and I'll copy it off before I shut the machine down
[05:04] <glatzor> bryce: ./displayconfig-gtk -w FILENAME should be enough
[05:05] <bryce> hmm, I get a "no such option: -w" error
[05:05] <bryce> I must not be on the right branch or something
[05:06] <cjwatson> sits: hang on ...
[05:06] <cjwatson> sits: any chance I could get a dd of the first 64K or so of /dev/sda1?
[05:06] <sits> sure thing
[05:06] <glatzor> bryce: https://code.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu
[05:07] <sits> one other thing while I remember
[05:07] <cjwatson> sits: oh, could I also have the output of 'mount'?
[05:07] <cjwatson> sits: was /dev/sda1 perhaps mounted before starting the installation?
[05:07] <sits> when this happens a cancel window appears but clicking either button does not dismiss the cancel window or ubiquity
[05:07] <cjwatson> sits: IIRC that's a known bug, but less of an immediate concern
[05:07] <cjwatson> May 30 15:03:37 ubuntu hald: mounted /dev/sda1 on behalf of uid 0
[05:07] <sits> cjwatson: unlikely - partition was blanked previously
[05:07] <sits> hmm
[05:08] <sits> ok lets get this dd to you
[05:08] <cjwatson> that's supposed to be suppressed
[05:08] <cjwatson> sits: you said you blanked the partition table, but did you blank the whole disk?
[05:09] <cjwatson> it looks like there was an NTFS partition there before, maybe
[05:09] <ogra> cjwatson, you will be pleased to hear that we found a better way for unencrypted X traffic in ltsp so we wont need cipher=none anymore ...
[05:09] <cjwatson> very pleased :-) what was it?
[05:10] <ogra> well, instead of using -X in ssh we export the DISPLAY ...
[05:10] <sits> cjwatson: http://cs.swan.ac.uk/~cssits/ub/
[05:10] <sits> cjwatson: no not the disk
[05:10] <jdub> "Tested to work fine with Ubuntu-based Linuxes" -- from auspcmarket.com.au motherboard listing
[05:10] <ogra> which gives us encrypted password handling from ssh but the same X transport as XDMCP
[05:10] <ogra> so its even better than cipher=none :)
[05:11] <sits> cjwatson: however it seems extreme that hal is picking up old partitions inbetween repartitiong and formatting though
[05:11] <sits> cjwatson: if it is (perhaps it sees the "new" partitions striaght after the partition table is reloaded) then I guess that behaviour needs to be surpressed until the formatting is complete
[05:12] <cjwatson> sits: it's supposed to be already :-/
[05:12] <cjwatson> pitti: help
[05:13] <pitti> cjwatson, sits: hal is triggered whenever udev detects a new partition
[05:13] <sits> ok
[05:13] <cjwatson> how do I stop it? I'm already suppressing gnome-volume-manager
[05:14] <pitti> it'll run volume id and stuff, so it shouldn't yield an usable partition (that's a race condition, of course)
[05:14] <pitti> cjwatson: there is no way to do that ATM short of stopping hal completely (but that shuold be avoided, too)
[05:14] <pitti> cjwatson: I can teach hal to suppress picking up new volumes 
[05:14] <sits> Doesn't hal have a "suepend for X seconds" option?
[05:15] <pitti> cjwatson: either with a file-based flag, or a hal-set-property call in the computer object
[05:15] <sits> I guess it could be used to DoS but what if it were only callable by root?
[05:15] <pitti> sits: not that I know of
[05:15] <sits> ok
[05:15] <pitti> sits: hal-set-property can only be called by root anyway
[05:15] <sits> ok
[05:16] <bhale> ogra: can i pm you?
[05:16] <pitti> cjwatson: if we had that, we wouldn't need to stop g-v-m and the KDE/XFCE mount daemons any more
[05:16] <cjwatson> is there any way to temporarily set volume.ignore for everything?
[05:16] <cjwatson> I guess not, but ...
[05:16] <ogra> bhale, sure
[05:16] <pitti> cjwatson: there might be actually
[05:17] <pitti> cjwatson: you could drop a temorary FDI into /usr/share/hal/fdi, but I have to verify whether they are only parsed at hal startup or for every device (I think the former, though)
[05:17] <pitti> cjwatson: let me try this
[05:18] <cjwatson> pitti: sounds risky
[05:19] <sits> the idea of zeroing the starts of partitions before repartitioning seems extreme but...
[05:20] <sits> (just wait until the wrong partition gets zeroed...)
[05:20] <cjwatson> sits: disabling hal would be a lot simpler and safer, I think
[05:20] <cjwatson> sounds like you were just unlucky enough to run into a race condition
[05:21] <sits> Isn't it dangerous to stop hal
[05:21] <pitti> cjwatson: verified, FDI are parsed at startup (makes sense, since that's expensive); so WDYT about the 'computer' property to disable volume detection temporarily? (hal-set-property call)
[05:21] <pitti> sits: /etc/init.d/hal stop would be indeed wrong, yes
[05:21] <sits> ok
[05:21] <pitti> sits: I just propose to inhibit volume detection
[05:22] <cjwatson> pitti: sounds fine to me
[05:22] <sits> cjwatson: do you want me to archive the first 1Mbytes of this disk?
[05:22] <cjwatson> sits: sure
[05:24] <sits> cjwatson: ok do you need anything else off this machine?
[05:25] <cjwatson> sits: I think that's all, thanks
[05:25] <sits> ok
[05:28] <keescook> mornin'
[05:29] <bryce> heya keescook
[05:29] <Hobbsee> morning keescook 
[05:29] <bryce> thanks for the xorg-docs upload
[05:29] <bdmurray> howdy keescook 
[05:29] <keescook> hiya bryce, Hobbsee, bdmurray :)
[05:30] <pitti> it's a Kees!
[05:30] <keescook> bryce: sure thing!  do you have time right now to work on beating beforelight into shape?
[05:30] <keescook> hey pitti :)
[05:30] <pitti> good morning!
[05:30] <bryce> keescook, sure
[05:31] <bryce> glatzor: I got it working; I'm gathering pci tables presently; will upload in a few minutes
[05:31] <glatzor> bryce: cool
[05:35] <bdmurray> bryce: can you look at 117631 when you have a moment?
[05:36] <bryce> bdmurray: ok, will do a bit later
[05:42] <pitti> so, ddeb-retriever works correctly now with all feisty pockets and gutsy
[05:54] <bryce> glatzor: http://people.ubuntu.com/~bryce/PciTables/
[05:55] <glatzor> pitti: apport is really hot stuff!
[05:55] <glatzor> bryce: fine
[05:56] <pitti> glatzor: does your hook work?
[05:57] <glatzor> pitti: I am writing it at the moment, but will test it in a minute.
[05:58] <bdmurray> cjwatson: doesn't the oem install method cover most of bug 117084?
[05:58] <pitti> glatzor: grab me if you want some help
[05:58] <ubotu> Launchpad bug 117084 in Ubuntu "Ubuntu needs a "sysprep"-like tool, like Windows has" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117084
[06:01] <cjwatson> bdmurray: yeah, sounds like he just missed it, although there are a few bits in there that could be useful enhancements for oem-config
[06:01] <cjwatson> I'll reassign, thanks
[06:02] <bdmurray> cjwatson: thank you
[06:02] <sits> :(
[06:02] <sits> Evesham just shipped out a "replacement" machine that seems to be of a worse spec than the broken one originally sent in
[06:03] <mjg59> sits: IBM just shipped me back a laptop with a hole in it
[06:03] <sits> mjg59: ah but where was the hole?
[06:04] <mjg59> The back of the screen
[06:04] <sits> ok now getting out of that one
[06:04] <sits> s/now/no
[06:04] <sits> mjg59: did they even know who you were? I'm sure they wouldn't have done that if they had.
[06:05] <mjg59> Haha
[06:05] <mjg59> They have other things to worry about
[06:06] <ogra> mmh, a spy laptop ... like the newspapers where you rip holes in the pages to look through :)
[06:08] <bryce> bdmurray: on bug 117631, that's interesting, I didn't know the installer picked out pci slots to use.  I don't know what inserts that but can take a look into it when I get some time.  
[06:08] <ubotu> Launchpad bug 117631 in Ubuntu "Dell Optiplex GX50, Cannot Install From CD" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117631
[06:08] <bryce> bdmurray: I'd guess that removing it might make this guys' system work, but break other people's systems
[06:09] <bdmurray> bryce: okay, I wasn't sure if you had heard of it before
[06:09] <sits> (one last point against evesham - their BIOSes routinely fail to fill in all the fields)
[06:09] <bryce> bdmurray: nope, it's new to me
[06:15] <slmnhq> I'm working on an ethernet driver, developing on dapper, kernel 2.6.17
[06:15] <slmnhq> I am seeing the following message: "BUG soft lockup on CPU #1"
[06:16] <glatzor> pitti: hm. I crashed my app, a crash file was created but without my extra files and apport does not want to send a report?
[06:16] <slmnhq> (it's a dual core intel machine)
[06:16] <glatzor> pitti: I am on feisty
[06:16] <slmnhq> the syslog has a traceback ... do you think if I pasted that, some one could help me figure out what might be going on?
[06:17] <pitti> glatzor: right, the hooks are not called before apport-gtk
[06:17] <pitti> glatzor: touch /var/crash/*; /usr/share/apport/apport-gtk  -> does that work?
[06:18] <pitti> glatzor: (the 'touch' because you seem to have already looked at the .crash file)
[06:18] <glatzor> pitti: it complained that the package was not supported
[06:19] <glatzor> pitti: does it check for modifcations?
[06:19] <glatzor> pitti: I added a raise statement to my script
[06:19] <pitti> glatzor: it does check for mods, yes, but the crashed file needs to be packaged
[06:20] <pitti> glatzor: where is that script?
[06:20] <glatzor> /usr/bin/displayconfig-gtk
[06:21] <keescook> hmmm, is there a simple way to calculate the delta between 6.06.1 and "current"?  I'm having trouble figuring out where to find the 6.06.1 versions of things.  the seeds just list packages, not versions.
[06:21] <pitti> glatzor: right, so the initial report is written because that looks like packaged; but it is not?
[06:22] <glatzor> pitti: I finally found a way to crash the script shipped in feisty :)
[06:23] <sits> wow
[06:23] <sits> 9 minutes to install Ubuntu
[06:23] <sits> (and that includes the time I speant typing stuff and waiting for it to boot)
[06:25] <glatzor> pitti: hm it ignored my hook :/
[06:26] <glatzor> pitti: https://bugs.launchpad.net/ubuntu/+source/displayconfig-gtk/+bug/117791
[06:26] <ubotu> Launchpad bug 117791 in displayconfig-gtk "[apport]  displayconfig-gtk crashed with TypeError in on_treeview_gfxcards_cursor_changed()" [Undecided,Unconfirmed]  
[06:26] <pitti> glatzor: oh, btw, you can see at the result of the hook information adding in the 'Details' expander
[06:26] <pitti> glatzor: no need to actually file a bug
[06:27] <QG> hello all
[06:27] <pitti> glatzor: what's the path of the hook and what does dpkg -S /usr/bin/displayconfig-gtk say?
[06:27] <pitti> glatzor: -> /query
[06:27] <vprints> Bug #117783 - Openoffice crash
[06:27] <ubotu> Launchpad bug 117783 in openoffice.org2-amd64 "presentation offer for a document recovery on close" [Undecided,Confirmed]  https://launchpad.net/bugs/117783
[06:27] <glatzor> pitti: http://paste.ubuntu-nl.org/23282/
[06:27] <QG> I am dedicating the next one hour of my life to bugsquading
[06:28] <QG> I've read all the recommended reading material
[06:28] <QG> Can someone guide me to an easy bug to start with. Never done this before
[06:28] <Hobbsee> QG: i think you wanted #ubuntu-bugs?
[06:29] <glatzor> pitti: renate@renate-laptop:~$ dpkg -S /usr/bin/displayconfig-gtk
[06:29] <glatzor> displayconfig-gtk: /usr/bin/displayconfig-gtk
[06:29] <Hobbsee> hmmm.  or it pointed here.  #ubuntu-bugs is where people are talking about bugs atm
[06:29] <QG> isn't the bug-day on #ubuntu-bugs?
[06:29] <glatzor> pitti: it is the default package from feisty
[06:29] <glatzor> I just added the hook
[06:29] <QG> I mean on #ubuntu-devel?
[06:29] <pitti> glatzor: did you see my /query?
[06:30] <Hobbsee> QG: it's either.  usually it's #ubuntu-bugs.  this channel is slightly noisy now with development talk, so the bug talk is in -bugs
[06:30] <QG> hobbsee: thank you
[06:30] <Hobbsee> no problem
[06:32] <ogra-classmate> Keybuk: do you plan to merge initramfs-tools from debian or are we to far off for a merge ?
[06:33] <ogra-classmate> (there is one fix in 0.88 i'd need in ltsp)
[06:57] <cjwatson> keescook: unfortunately 6.06.1 is only really recorded in the CD builds and in a massive hardlink tree I have on drescher
[06:58] <cjwatson> when Launchpad's data model is capable of capturing it, we plan to feed all that data back in somehow
[06:58] <keescook> cjwatson: okay, thanks
[07:00] <ubuntulover> hey all - when you install a new kernel in feisty, where does the package pull the uuid from to add to menu.lst -- its incorrect and i want to change it
[07:01] <Lure> Mithrandir: can you giveback strigiapplet (now that strigi hit the repo)?
[07:02] <bdmurray> ubuntulover: try using vol_id /dev/partiitonhere
[07:03] <ubuntulover> bdmurray: i understand that - just when i install a new kernel it updates it with an old UUID
[07:03] <ubuntulover> i migrated to a new harddrive but on every kernel install the menu.lst is all wrong
[07:05] <AndyP> ubuntulover: could be the # kopt= line in menu.lst (it's commented out but update-grub still uses it)
[07:06] <glatzor> bryce: thanks to the help of pitti we now have got a working apport package hook, that also submits pcitable and xorg.conf. perhaps it gets time for a new release :)
[07:08] <bryce> glatzor, excellent!!
[07:08] <bryce> yes I still need to finish adding the apport hook for xorg-server
[07:09] <adam0509> hi, do someone knows why xorg is sooo slow on old computer (PII/PIII ans SDRam) ?
[07:09] <adam0509> even with xubuntu or fluxbox... :/
[07:25] <ubuntulover> are there any ubuntu scripts / packages to reconfigure that would regenerate an fstab file?
[07:25] <ubuntulover> with new uuid's, etc?
[07:26] <ogra-classmate> ubuntulover: a) see topic, no support here b) have a look at vol_id
[07:26] <ogra-classmate> ;)
[07:27] <ubuntulover> ogra-classmate: thanks! -sorry bout the topic
[07:48] <rrivasdiaz> Does anybody knows if the spec NoMoreSourcePackages will be implemented? any plans?
[07:49] <rrivasdiaz> I think that this specification not only will help package management, I think it has the potential to atract a lot of developers
[07:50] <ogra-classmate> rrivasdiaz: thats rather an ongoing process than a spec
[07:51] <rrivasdiaz> Any time I have tried to read all the information required to make a package I have ended quitting. If all this boilerplate is generated and maintained authomatically, I will be a lot easier to contribute
[07:52] <rrivasdiaz> I'm a good coder with skills in C/C++ and Java. And I really want to contribute, but sadly I haven't enough time to read all the documents required to make a package, the process looks too complicated.
[07:53] <rrivasdiaz> I just want to checkout something, make the changes and submit a patch. This process is well known to me. But making a debian source package is not.
[07:54] <robertj> rrivasdiaz: it looks pretty dead to me
[07:54] <ogra-classmate> well, but you can do the same with an existing debian source package with no problems
[07:54] <ogra-classmate> apt-get source blah
[07:54] <robertj> (btw, how do you run debuild without patching again?)
[07:54] <ogra-classmate> cp -a blah-version blah-version,orig
[07:54] <ogra-classmate> cd blah-version
[07:55] <ogra-classmate> hack around
[07:55] <ogra-classmate> cd ..
[07:55] <ogra-classmate> diff -ruN blah-version blah-version.orig >mypatch
[07:55] <ogra-classmate> attach mypatch to a bug
[07:57] <ogra-classmate> rrivasdiaz: its just a different process and ends with a link to a bzr branch instead of a patch on the bug
[07:57] <ogra-classmate> but it makes reviewing the patches way easier and merging as well indeed
[07:59] <robertj> ogra-classmate: is there some kind of vcs-agnostic library that is in-the-works?
[07:59] <rrivasdiaz> I have submited a simple patch once (for dapper), but the maintainer didn't had time to review it. It was very simple, but anyway it is not included yet. I think that using the source control will be a lot easier for the maintainers to review and include a patch
[08:00] <ogra-classmate> not that i know of ... but then i'm no resident in #bzr :)
[08:00] <ogra-classmate> rrivasdiaz: right and many of us already maintain a lot in bzr
[08:00] <robertj> ogra-classmate: I was just thinking it might be hard to get say...svn to put their source code in bzr
[08:00] <ogra-classmate> but there are a lot of packages and only so many developers
[08:01] <ogra-classmate> so unless we have an automated import to launchpad for upstream or debian NMSP wont happen as a whole only where ressources arre available
[08:02] <rrivasdiaz> Automatically importing from upstream, atomated testing of submited patches, a lot of new stuff could be implemented using a version control system
[08:03] <robertj> is grumpy still a long-term goal?
[08:04] <rrivasdiaz> orga-classmate: do you know how can I help to achieve this?
[08:05] <robertj> rrivasdiaz: realistically I would think it would take man-decades to get that working
[08:05] <rrivasdiaz> orga-classmate: really?? that's too bad :-(
[08:08] <rrivasdiaz> orga-classmate: anyway the current scheme is too complicated for people to contribute. I have suffered the problems with today's state of managing distribution code.
[08:12] <ogra-classmate> well, NMSP will happen eventually, we're working on it :)
[08:12] <ogra-classmate> but dont expect it to be tomorrow ;)
[08:12] <robertj> so what is the plan for non-bzr packages?
[08:13] <ogra-classmate> there wont be any ?
[08:13] <robertj> so the bzr packages aren't neccecerrily upstream?
[08:13] <ogra-classmate> thats why the spec is called no more source packages :)
[08:13] <robertj> err not packages/repos
[08:14] <ogra-classmate> not if you have an importing mechanism that makes them bzr branches
[08:25] <glatzor> bryce: xrandr does not seem to like xinerama :) I can break my dual screen layout on a regular basis by changing the size
[08:26] <bryce> yeah
[08:26] <glatzor> bryce: furthermore we are going to see a separated guidance backend very soon
[08:34] <bryce> glatzor: excellent
[08:38] <glatzor> bryce: the on screen displaying of the monitor names could be done for xinerama mode, but only in a very hackish way
[08:39] <glatzor> bryce: I can get the monitor resolutions and positions from the gtk display
[08:40] <glatzor> bryce: but the combination with the xorg.conf settings can only be done by guessing :/
[09:18] <mathiaz> I'm trying to understand the init/rc scripts. What is the role of rcS ? Are these scripts run before any runlevel scripts ?
[09:22] <cjwatson> rrivasdiaz: I don't think no-more-source-packages would really solve the problem of developers not having time to review and apply changes, anyway
[09:22] <cjwatson> it might help a bit, but I think it's a mistake to view it as a magic bullet there
[09:24] <rrivasdiaz> cjwatson: yep, you are right. But with this system you can have in the future an automated way of testing patches, for example. At least in Java that's very feasible and not at all dangerous.
[09:24] <rrivasdiaz> cjwatson: also if with that system you can get more developers, ubuntu comunity will have more resources to test patches.
[09:25] <cjwatson> (most of our code is not in Java and can only be entirely safely sandboxed by running a complete virtualised system)
[09:25] <cjwatson> I'm not saying it wouldn't help, just saying it's not a panacea
[09:27] <enrico> Hi.  I wanted to take small bits of libapt-pkg and reuse them in a library of mine which is LGPLed.  libapt-pkg is GPL, so I'd need to ask the devels about it.  Turns out it's more likely I'll find them here than in #debian-devel
[09:28] <enrico> It mostly boils down to the pkgTagFile class in tagfile.{h,cc}
[09:28] <enrico> I'd like to ship a modified version of it
[09:29] <Toxicity999> rawr wvdial/pppd are not respecting my DNS choices =] 
[09:30] <Toxicity999> And I said that in the wrong channel by mistake, My griping skills are highly unleet.
[09:32] <rrivasdiaz> cjwatson: Anyway I think this scheme could attract more developers. Athough I work with software all the time, I still feel scared with debian source packages. And I think a lot of developers are like me. It's much easier to use a source control. So I'm all for this spec.
[09:33] <rrivasdiaz> cjwatson: That's way I want to help with this. Could you tell me how can I?
[09:35] <crimsun> seb128: yes, I do get said crash (hence setting to Confirmed)
[09:35] <seb128> crimsun: that was not clear since you didn't comment on the bug ;) I was going to ask for a backtrace but the submitter already sent one so that's alright
[09:35] <rrivasdiaz> Also the branch support in source control systems allows you to work on more complex patches. I wanted to change the way Java virtual machines are configured in ubuntu and I proposed a list of changes but no one followed me so I couldn't get support form my idea.
[09:36] <crimsun> seb128: sorry, was in a rush this morning to the airport
[09:36] <seb128> no problem
[09:38] <cypherbios> Riddell: Hi. Do you know if KDE follows the FreeDesktop guidelines for icon names?
[09:38] <rrivasdiaz> cjwatson: I wanted to develop it, but I would be a big patch and I lost interest 'cause it would be dificult for me to push this as a big patch. But if I had a way to develop in an alternate branch it could be easier for others to test it.
[09:38] <cypherbios> have a standard to describe a icon for the application-x-deb mime? I'm writing a application (in gtk) which in gnome I use the icon name 'gnome-mime-application-x-deb' or just 'deb' but when in a fresh Kubuntu installation (without the gnome-icon-theme) it looks very ugly (without any icon).
[09:44] <Riddell> cypherbios: KDE 3 doesn't, KDE 4 does
[09:45] <Riddell> cypherbios: is this an icon for your application (e.g. in the application menu?)
[09:46] <cypherbios> Riddell: No. Inside the application I show the icon of a package (a debian package, in this case) to represent each package in the treeviewlist
[09:47] <Riddell> cypherbios: well if it's a gnome app then it'll load the gnome icon theme regardless of which desktop you run it under, so it should depend on the gnome icon theme
[09:48] <cypherbios> Riddell: yes, that's right. But I don't want to add the gnome-icon-theme as dependency for the Kubuntu users
[09:48] <cypherbios> I'd prefer to use a KDE icon instead
[09:49] <Riddell> cypherbios: well /usr/share/icons/crystalsvg/32x32/mimetypes/deb.png is the KDE 3 icon, but then you'd have to depend on kdelibs to ensure that exists
[09:50] <cypherbios> Riddell: but in this case I must to point the fullpath to the png file?
[09:50] <cypherbios> Riddell: just to let you know the way the image is used: http://img79.imageshack.us/img79/5610/screenshotaptoncdll2.png
[09:51] <Riddell> well yes, you either use the icon theme stuff and accept what the library gives you or you use a full path
[09:51] <Riddell> adept has its own icon of course :)
[09:52] <cypherbios> Riddell: ah sure. But as it's not installed in my computer, the application icon is showed only if the package is installed ;)
[09:52] <cypherbios> Riddell: if it's not installed, then show the generic icon ('deb')
[09:53] <Riddell> cypherbios: you might be able to find a lot of app icons from app-install-data
[09:53] <cypherbios> Riddell: I'm trying to give the KDE users a less painful experience with aptoncd as possible
[09:54] <cypherbios> Riddell: sure, I'll take a look on it.
[09:55] <cypherbios> Riddell: I already removed the yelp and nautilus-cd-burn dependencies and now aptoncd checks if its exists before trying to use it (I can't find a way to replace yelp by khelpcenter to show .xml files =(
[09:57] <mantiena> Hi all
[10:03] <cypherbios> Riddell: sorry for bugging, but could you say if is possible with adept add a cdrom as apt source (graphically) just like synaptic does (synaptic --ask-cdrom). Currently I use synaptic to do this operation, but if adept is able to do the same I will use adept if the user is running KDE
[10:03] <cypherbios> I mean, aptoncd calls synaptic this way, not me ;)
[10:18] <pitti> yay changelog-closes-bugs!!!
[10:19] <ion_> Its implemented now?
[10:19] <LaserJock> pitti: looks like texlive-bin can be synced again
[10:20] <pitti> ion_: mdz just annouced it on the list
[10:20] <pitti> LaserJock: yay, did they take all our patches? nice
[10:20] <LaserJock> pitti: 2007-10 closes your bug and dholbachs as well
[10:21] <ion_> pitti: Rock
[10:21] <pitti> LaserJock: not sure why we need the -fPIC; it sounds important
[10:21] <pitti> LaserJock: if the .so is really built without -fPIC, that would be a bug
[10:22] <mantiena> I don't know where I should report a bug about incorrect mapping of lt.archive.ubuntu.com (it should redirect to official Lithuanian Ubuntu mirror - ftp.litnet.lt/pub , but redirrects to some very slow, non-lithuanian server)
[10:22] <glatzor> cypherbios: you can take a look at software-properties for the add-cdrom dialog
[10:23] <LaserJock> pitti: dholbach's changelog indicates it was causing a FTBFS for 64bit evince 
[10:23] <glatzor> cypherbios: I think that the kde port already has got a cdrom import dialog
[10:23] <cypherbios> glatzor: Actually I need to do it in a single command-line call method to keep it transparent
[10:23] <mantiena> this bug exists more than 2 years, maybe from the Ubuntu start and couses a lot of problems, because all Lithuanians get a mirror with ~20kb/sec speed after installation :(
[10:24] <glatzor> cypherbios: you could just add a command line option to software-properties :)
[10:24] <cypherbios> glatzor: The software-properties-kde have a button that does it, I'll look at the code what it calls to add a cd
[10:24] <Lure> pitti: if code was just moved from main package in new library, does this simplify MIR
[10:24] <pitti> LaserJock: right, it's easy to check
[10:24] <Lure> pitti: I have prepared MIR anyhow: https://wiki.ubuntu.com/MainInclusionReportLibKdcraw
[10:25] <pitti> Lure: it usually doesn't need an MIR at all, just a quick package review from me
[10:25] <pitti> Lure: good
[10:25] <Lure> pitti: ok, great 
[10:25] <cypherbios> glatzor: the software-properties-gtk users synaptic to add the cd, and software-properties-kde uses what?
[10:28] <glatzor> bryce: I now show a single button on every monitor that allows to move the config dialog to it. furthermore I ask the window manager to please always center the dialog. metacity now places it on the center of the screen it was launched from. but I don't know what compiz does ... :)
[10:30] <glatzor> cypherbios: Sorry, I am not so familiar with the kde frontend, since I only worked on the backend and GTK frontend
[10:31] <glatzor> cypherbios: but wasn't the GTK frontend using python-apt?
[10:32] <cypherbios> glatzor: I think the part of adding a CD as APT source is done by Synaptic (with --ask-cdrom)
[10:32] <cypherbios> it, of course, in the gtk front end -- I guess
[10:32] <bryce> glatzor: good to hear it's centering, that was a big bug
[10:33] <bryce> bbs (lunch)
[10:34] <glatzor> cypherbios: take a look at on_button_add_cdrom_clicked in softwareproperites/gtk/SoftwarePropertiesGtk.py
[10:35] <cypherbios> softwareproperties/kde/SoftwareProperties.py:707 
[10:36] <cypherbios> glatzor: hum, I see. Indeed it doesn't uses synaptic as I thought
[10:38] <cypherbios> glatzor: so a command-line paramether wouldn't be bad for both software-properties-{kde|gkt} --add-cdrom :)
[10:41] <cypherbios> glatzor: thank you for the attention
[10:42] <cypherbios> I'll use part of the code from s-p-{gtk|kde} in the implementation of this
[10:44] <glatzor> cypherbios: the dialog is still a bit ugly. but I would be happy to merge a patch from you
[10:46] <cypherbios> glatzor: Thanks. I'll do my best and if I have any progress I'll be glade to share it in a patch
[10:54] <cjwatson> rrivasdiaz: I think it really needs an expert in the existing source package format to get it started, but you could talk to Keybuk
[10:55] <rrivasdiaz> cjwatson: thanks
[10:57] <cjwatson> (and I do think attracting more developers is very important; this is just one of the several things we should be doing along those lines)
[11:01] <glatzor> night
[11:37] <Seveas> Keybuk, poke
[11:40] <tepsipakki> Seveas: any news of falcon for feisty?
[11:41] <tepsipakki> s/for/which works on/
[11:41] <Seveas> tepsipakki, I found a few nasty bugs so I wasn't abl to release it on Monday
[11:41] <Seveas> but it's getting real close, I use it already to manage my own repo
[11:41] <tepsipakki> excellent :)
[11:41] <Seveas> this wekend should be doable
[11:42] <tepsipakki> is it compatible with the old version?
[11:42] <tepsipakki> the generated repo, that is
[11:42] <tepsipakki> not that it's a big deal for me
[11:42] <Seveas> it is compatible with the old pool structure 
[11:43] <tepsipakki> ok, cool
[11:43] <Seveas> but the config is different and the command line arguments as well (not to mention rewriting the entire core, but that's not too visible from the outside)
[11:44] <tepsipakki> right, I'll just wait a few days then :)