[12:41] <ailean> composite-by-default has been deferred? :(
[12:49] <gnomefreak> ailean: not sure i know a package was rejected because it didnt build fine
[12:50] <ailean> gnomefreak, i just see the deferred notice on LP
[12:50] <ailean> gnomefreak, i hope not - i really think it's what ubuntu and desktop linux needs
[12:51] <gnomefreak> i never looked i think its a  big thing with the binary drivers by default
[12:51] <ailean> well of course i understand that
[12:51] <ailean> sabdfl convinced me on the subject though :)
[12:52] <gnomefreak> it was a good idea and i know the beryl devs are working towards it but the binary thing and the fail to build maybe why its deffered but i never saw the notice.
[12:52] <Burgwork> I never saw it either
[12:53] <ailean> nahh, i just mean that it's marked as deferred. i didn't see any statement or anything
[12:53] <gnomefreak> beryl-core was i heard a FTB
[12:53] <gnomefreak> you have link handy?
[12:54] <ailean> https://blueprints.launchpad.net/distros/ubuntu/feisty/+specs
[12:54] <gnomefreak> ty
[12:54] <ailean> https://blueprints.launchpad.net/distros/ubuntu/+spec/composite-by-default even
[12:55] <Burgwork> I just don't see any notice in my email, which is odd
[12:55] <ailean> Burgwork, don't worry -  i haven't received any email about it or anything
[12:55] <ailean> misunderstanding :)
[12:55] <gnomefreak> it would have been in feisty-changes?
[12:55] <ailean> all i saw was the word "deferred"
[12:56] <ailean> well i'm subscribed to this feature and didn't receive any email about it
[12:56] <Burgwork> it could be that those changes don't trigger bug mail, which is odd
[12:57] <ailean> it's just weird that it's essential, but deferred :)
[12:57] <Burgwork> not the only spec
[12:58] <ailean> surely if it was essential, they'd find the time to work on it :D
[12:58] <gnomefreak> i will find out from the effects team whats going on im sure someone there knows. wish i was able to be kept up-to-date being owner of it
[01:00] <ailean> lol
[01:01] <ailean> is it possible that some eedjit just went in and changed it without anyone's knowledge?
[01:01] <ailean> no. it won't let me
[01:02] <ailean> i'm not important enough
[01:02] <Burgwork> only keybuk or sabdfl can do that
[01:02] <gnomefreak> keybuk isnt on atm maybe ill ping him later im sure he did it
[01:03] <gnomefreak> asbdfl wanted it way too bad to deffer it this early i would think
[01:03] <Burgwork> mdz may also have done it, now that I think about it
[01:03] <gnomefreak> s/asbdfl/sabdfl
[01:03] <gnomefreak> he can change it?
[01:05] <ailean> i'm glad you agree it's strange
[01:05] <Burgwork> yes, as he is the registrant
[01:06] <ailean> unless they decided to go with the metacity composite work . . .
[01:06] <gnomefreak> beryl-core must really be screwed up if the FTB is the reason
[01:06] <ailean> FTB?
[01:06] <ailean> failure to build?
[01:06] <Burgwork> FTBFS is the more common term
[01:06] <Burgwork> the metacity stuff is dead
[01:07] <ailean> what about compiz though, that was a serious option
[01:07] <Burgwork> soren is now working on compiz
[01:07] <ailean> why is it dead?
[01:07] <Burgwork> because it is
[01:07] <ailean> no one working on it?
[01:07] <bhale> s'what he said
[01:08] <ailean> yeah, it doesn't quite explain though :)
[01:08] <bhale> soren wrote it, and has since moved on to compiz
[01:08] <bhale> it happens
[01:08] <ailean> oh right
[01:09] <Burgwork> compiz has major issues as well
[01:09] <Burgwork> I wonder if my blog post has anything to do with this
[01:10] <ailean> someone's changed it
[01:11] <ailean> cool, back to drafting
[01:11] <ailean> i'm happier
[01:12] <Burgwork> hmm, just changed again
[01:12] <ailean> not for me
[01:13] <Burgwork> changed from deferred to not started
[01:13] <gnomefreak> yes its fixed just waits for upload to hit repos :)
[01:14] <ailean> this was the one feature i wanted to see in the default installation
[01:17] <ailean> hrm . . . "Sony Adds PS3 Support to Linux Kernel" http://games.slashdot.org/article.pl?sid=06/12/07/211214
[02:13] <frandavid100> hello
[02:13] <frandavid100> I'd like to file a bug against the open dialog, what package would be the correct one?
[02:17] <frandavid100> anyone there?
[02:18] <xerxas> the open dialog ?
[02:18] <frandavid100> the open file dialog that appears on any gnome app
[02:19] <frandavid100> since it's the same in every app, I assume it must be a separate package
[02:19] <xerxas> I don't understand
[02:19] <xerxas> but maybe I don't have enough knowledge 
[02:20] <xerxas> ok 
[02:20] <xerxas> sorry 
[02:20] <xerxas> I got it 
[02:20] <xerxas> that should be gtk ? 
[02:20] <xerxas> not sure 
[02:20] <crimsun> if you mean the file chooser, yes, that's gtk+2.0
[02:20] <frandavid100> well I could try filing it in gtk
[02:21] <frandavid100> you sure?
[02:21] <frandavid100> fine then thanks ^^
[02:27] <frandavid100> alright, bug filed
[02:27] <frandavid100> https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/74907
[02:27] <Ubugtu> Malone bug 74907 in gtk+2.0 "nautilus and the "open file" dialog" [Undecided,Unconfirmed]  
[02:27] <frandavid100> thanks for your help guys, good night!
[02:27] <crimsun> seb's going to have a field day with that one.
[03:46] <wasabi> anybody able to speak as to the installability of a feisty daily cd build?
[03:47] <wasabi> (i have a system that requires 2.6.18+)
[03:53] <jdong> wasabi: early today it was mentioned that e-d-s was uninstallable
[03:53] <jdong> wasabi: I'd still say get a herd1 cd :)
[03:54] <wasabi> grabbing the latest daily build right now. i'll grab a herd1 just in case.
[03:54] <wasabi> need a solution when i get into work tomorrow. =/
[03:54] <wasabi> new intel mobo. achi stuff.
[03:54] <wasabi> ahci
[03:55] <jdong> ouch
[03:55] <jdong> yeah
[03:55] <wasabi> Wonder how hard it would be to backport feisty's kernel to edgy.
[03:56] <wasabi> probably pretty easy... would just have to go through the trouble of actually making a custom installer.
[03:56] <kylem> eh? why bother, what pci ids? you can probably work around.
[03:56] <wasabi> hmm. guess a usb cdrom drive would solve the problem too.
[03:56] <wasabi> It just can't read the IDE CDRom.
[03:56] <wasabi> It gets the SATA drives fine though.
[03:57] <kylem> hmm.
[03:57] <jdong> kylem: lack of chipset support :(
[03:58] <jdong> kylem: it's a known issue with like the Core 2 Duo desktop chipsets
[03:58] <jdong> like the 965/975's
[03:58] <wasabi> ayup. that'd be me.
[03:58] <jdong> they have really odd IDE chipsets
[03:58] <wasabi> dg965
[03:58] <jdong> that were merged in 2.6.18
[03:58] <jdong> we tried backporting to 2.6.17 but none of those cherrypicks seem complete enough
[03:58] <wasabi> are they odd as in "new" or odd as in "stupid?"
[03:59] <jdong> wasabi: new
[03:59] <jdong> as in, instead of a shiny well supported intel ICH* chipset
[03:59] <jdong> you get some random unknown company's cheap IDE chipset
[03:59] <kylem> hmm.
[03:59] <jdong> though the SATA chipset is the awesome ICH one
[03:59] <kylem> we'll see.
[04:00] <wasabi> Ahh. So it's just the IDE chipset.
[04:00] <wasabi> The SATA is fine?
[04:00] <jdong> wasabi: exactly
[04:00] <wasabi> I might just run by fries and grab a SATA DVD writer to replace my current one then
[04:00] <wasabi> fry's
[04:00] <wasabi> and forget the entire problem.
[04:00] <wasabi> I meant to do it anyways.
[04:00] <jdong> that'll work :)
[04:01] <jdong> wasabi: and btw a Feisty kernel should build on Edgy with no problems
[04:01] <wasabi> suspected as much.
[04:01] <jdong> wasabi: you can actualyl just install feisty kernel debs on Edgy
[04:01] <wasabi> just have to get edgy installed first. ;)
[04:01] <jdong> EXCEPT the gui components in l-r-m aren't gonna work
[04:01] <jdong> you can install the linux-image packages
[04:01] <jdong> and you should rebuild l-r-m-2.6.19 if you need them
[04:01] <wasabi> With another CD drive, or setting up a PXE boot or some crap, I don't have anyway to get into a working system. :)
[04:02] <jdong> wasabi: I was told also that it behooves thee to backport initramfs-tools from Feisty too
[04:02] <wasabi> I'll probably just install feisty. I ran it before I got the new box at work anyways.
[04:02] <wasabi> I love breaking things.
[04:03] <wasabi> it's going to be a super quick box yum.
[04:03] <wasabi> 4 HD"s, RAID10
[04:03] <wasabi> e6600, 4gb ram.
[04:45] <cjwatson> jdong: backporting the feisty kernel to the edgy installer will be pretty messy unless you revert all the structural udeb changes
[04:45] <cjwatson> if you do that it should be possible ...
[04:46] <cjwatson> may not be worth it for one system, though
[04:47] <wasabi> i'll just install feisty.
[04:47] <wasabi> and cross my fingers that the installer works. ;)
[04:47] <bddebian> cjwatson: Hi.  Hey, how do I properly ask to get packages brought from Debian that are not currently being synced? (Not new packages but probably blacklisted?)
[04:47] <cjwatson> bddebian: check in http://people.ubuntu.com/~cjwatson/sync-blacklist.txt to see if they're blacklisted and why
[04:48] <bddebian> Hmm, not on that list
[04:48] <cjwatson> bddebian: if they aren't, they should be brought in automatically; just make a note to file bugs with ubuntu-archive subscribed shortly before UVF if they aren't
[04:48] <cjwatson> bddebian: example package?
[04:48] <bddebian> mig and gnumach
[04:48] <bddebian> And maybe hurd
[04:49] <bddebian> Because they are ports?
[04:49] <cjwatson> hurd only builds for an architecture we don't support, so that won't happen
[04:49] <cjwatson> well, it might get synced I guess but won't build
[04:50] <bddebian> Aye.  Hurds not as important for now but I would like to get mig and gnumach if at all possible
[04:50] <cjwatson> err, those are all in feisty
[04:50] <cjwatson>        mig |    1.3.1-2 | feisty/universe | source
[04:50] <cjwatson>    gnumach | 2:1.3.99.dfsg.1-1 | feisty/universe | source
[04:50] <cjwatson>       hurd | 20060825-2 | feisty/universe | source
[04:50] <cjwatson> all in sync with Debian
[04:50] <bddebian> Hmm, strange
[04:51] <bddebian> nevermind... Sorry
[04:51] <cjwatson> np
[04:51] <bddebian> Is that new?
[04:51] <cjwatson> wasabi: I don't know of daily build breakage right at the moment ... well, Kubuntu ubiquity won't be happy, but ...
[04:52] <wasabi> getting the alt image anyways
[04:52] <cjwatson> bddebian: no, not at all; those are all there right back to warty
[04:52] <cjwatson> bddebian: none of them have ever built though
[04:52] <bddebian> How the hell have I missed those.  Damn, I have GOT to get off the crack
[04:53] <cjwatson> bddebian: I suspect they need a manual bootstrap by infinity
[04:53] <bddebian> Not a big deal as long as the source is synced. Thanks man.
[04:58] <jdong> cjwatson: you're right, I didn't consider the installer... silly me :)
[04:58] <cjwatson> there are the following sources currently not blacklisted and not synced from Debian: attal-themes-medieval cdrskin etoile gnuradio iceape preview-latex python-gtk2-doc samizdat tagcoll2 xbase-clients xutils
[04:59] <cjwatson> I suspect all of those have problems of some kind that make sync-source bail out, and have to be thought about and resolved manually
[04:59] <cjwatson> for instance: E: tagcoll is in main but its source (tagcoll2) is not.
[05:00] <cjwatson> so tagcoll2 needs to be checked for suitability in main, and then forced in
[05:01] <bddebian> I thought I brought in a new attal-themes-medieval in edgy?
[05:02] <cjwatson> bddebian: it's not a source package in edgy; presumably built by another source
[05:02] <bddebian> cjwatson: Oh, I think it's built from attal now
[05:02] <cjwatson> looks like it got split out into a separate source package again in Debian, the way it was up to dapper, or similar
[05:02] <bddebian> Ahh. Hmm
[05:02] <cjwatson> again, that's the sort of thing that needs to be resolved manually
[05:03] <bddebian> Is that list posted somewhere?
[05:03] <cjwatson> no
[05:03] <bddebian> pastes even
[05:03] <cjwatson> probably should be, but you can ask an ubuntu-archive member to run 'new-source' in ~/syncs any time you're curious
[05:03] <cjwatson> (or in fact just run it, it cds itself)
[05:03] <bddebian> thx
[05:04] <cjwatson> that's just main - there are other lists for contrib and non-free
[05:04] <cjwatson> contrib: acx100 atokx2 dguitar doom-package dynagen freemind fst gcc-doc-defaults googleearth-package groovy gwp horae ifeffit imgtex ipw2200 ipw3945 jabref kfolding libvpopmail-perl nvidia-cg-toolkit ogre-contrib opendict-lingvosoft openjump penguin php4-vpopmail pose pose-skins premail psyco-doc python-doc-defaults python-lame python-ldap-doc python2.5-doc q-tools susv2 tuxguitar vpopmail xserver-xorg-video-ivtvdev
[05:04] <cjwatson> nothing for non-free
[05:05] <bddebian> gah, I don't "do" main :)
[05:05] <cjwatson> some of those should possibly be blacklisted (for now?), e.g. ipw3945 is in l-r-m
[05:05] <cjwatson> bddebian: Debian main not Ubuntu main
[05:05] <bddebian> I wondered
[05:06] <bddebian> Heh, gnight cjwatson, thanks
[05:06] <cjwatson> np
[07:36] <Kano> hi, are the tools used to create the standard live cds freely available
[07:37] <Kano> did not find usefull info in the wiki
[07:39] <crimsun> yes, see http://uck.sourceforge.net/ for example usage
[07:39] <Kano> thx
[07:40] <Kano> they are not really speedy but maybe it can be tuned a bit
[07:42] <Kano> did you ever think of sorting the image
[07:44] <crimsun> https://launchpad.net/distros/ubuntu/+spec/optimized-live-cd-layout-for-faster-boot
[07:47] <Kano> thx, will look into it
[07:49] <Kano> do you know how this is done with knoppix like cds?
[07:50] <crimsun> no, but Mithrandir may be interested
[07:51] <Kano> well i know how it is done manually. that basially works well, i c you use bootchart to optimize it
[07:51] <Kano> not bad that idea
[07:52] <Kano> opt. cds need a bit longer to install, but boot is faster
[08:02] <slomo> rodarvus: ping?
[08:11] <Kano> bye
[08:29] <pitti> Good morning
[08:30] <Burgundavia> morning pitti
[08:31] <pitti> hi Burgundavia, how are you?
[08:31] <Burgundavia> not bad
[08:33] <Burgundavia> need to sleep but waiting up for a conference call with jono and christina
[08:34] <pitti> heh, happy coffee drinking then
[08:35] <Burgundavia> yep
[08:36] <desrt> Burgundavia; can't be later than 11:30 there...
[08:36] <Burgundavia> yes, but the meeting is at 9am UTC
[08:37] <Burgundavia> and i hate skype
[08:37] <desrt> shouldn't y'all be using ekiga or something? :
[08:37] <desrt> :)
[08:38] <Burgundavia> yes, but it works less well
[08:38] <desrt> somewhere richard stallman is crying
[08:38] <Burgundavia> yes, he probably is
[08:38] <mneptok> good.
[08:39] <mneptok> cry for me, you stout little emo-hippie.
[08:39] <Burgundavia> given I run madwifi, he is already crying
[08:39] <Burgundavia> mneptok: you get very wierd when at work :)
[08:39] <mneptok> s/when at work//
[08:39] <desrt> "Those who are willing to give up their freedom for a little temporary video conference deserve neither freedom nor conferencing."
[08:39] <desrt> pitti; hi :)
[08:40] <Burgundavia> desrt: right
[08:40] <desrt> Burgundavia; ben franklin.  seriously.
[08:40] <desrt> the man was a visionary
[08:40] <Burgundavia> you want the actual quote?
[08:40] <desrt> i know it, thanks :p
[08:43] <mneptok> Franklin denied authorship
[08:44] <mneptok> (but it may still be him. no one will ever know for sure.)
[08:44] <desrt> for real?
[08:44] <mneptok> http://en.wikipedia.org/wiki/Those_who_would_give_up_Essential_Liberty
[08:47] <Kagou> hi
[08:48] <pitti> hi Kagou 
[08:48] <Kagou> hey pitti. How are you ?
[08:49] <pitti> Kagou: great, hacking on spec implementation like mad :)
[08:49] <Kagou> :)
[08:51] <Kagou> pitti: when i do a wish bug asking for a package sync from debian, must i assign someone to it ?
[08:52] <pitti> Kagou: no, but you need to subscribe ubuntu-archve
[08:52] <pitti> archive, even
[08:53] <pitti> Kagou: please read https://wiki.ubuntu.com/DeveloperResources, section 'syncs'
[08:53] <pitti> Kagou: it links to my script that does everything for you (almost)
[08:53] <Kagou> thanks pitti 
[08:59] <pitti> doko_: wrt cyrus-imapd2.2 merge, does Debian use 4.4 or a < 4.3 version?
[08:59] <doko_> pitti: 4.2
[09:00] <pitti> doko_: ah, ok; thanks
[09:05] <pitti> doko_: wrt bug 70957, shall I apply the patch myself or do you prefer doing that yourself?
[09:05] <Ubugtu> Malone bug 70957 in python2.5 "support apport reporting for python programs" [Wishlist,Confirmed]  http://launchpad.net/bugs/70957
[09:06] <doko_> pitti: I'm preparing new uploads for python2.4 and python2.5
[09:06] <pitti> doko_: ah, great
[09:13] <tepsipakki> does it need all buildd's to complete before a package is moved to archive?
[09:13] <pitti> tepsipakki: no
[09:13] <pitti> tepsipakki: sources go straight in
[09:14] <pitti> tepsipakki: and binaries come whenever a buildd finishes building them
[09:14] <pitti> tepsipakki: (in the non-frozen development release case, anyway)
[09:14] <tepsipakki> pitti: ok, thanks. I'm just wondering why evolution is not in yet, only ia64 build waiting, others completed
[09:14] <pitti> tepsipakki: probably stuck in NEW, due to a lib rename or so
[09:14] <tepsipakki> ah, ok
[09:15] <pitti> tepsipakki: https://launchpad.net/distros/ubuntu/feisty/+queue?start=20 -> there
[09:16] <pitti> hm, weird, that only talks about translations
[09:34] <Mithrandir> hmm, it should be possible (in malone) to say that you're not interested in bugs for a particular distribution.
[09:34] <Burgundavia> Mithrandir: there are a bunch of "don't bug me options", including the team membership one
[09:35] <Mithrandir> Burgundavia: no such twiddles on https://launchpad.net/people/ubuntu-archive/+subscribedbugs nor the advanced search.
[09:35] <Mithrandir> I'm not particularly interested in bugs which only affects baltix.
[09:35] <Mithrandir> (because they've been fixed in Ubuntu)
[09:40] <Fujitsu> Mithrandir: I've been looking for that option for a while too :(
[09:46] <opi> morning.
[09:50] <raphink> hi opi
[09:51] <lifeless> mvo: can I assign this to you ?
[09:51] <lifeless> https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/74899
[09:51] <Ubugtu> Malone bug 74899 in update-manager "crashed in saveDistUpgrade" [Undecided,Unconfirmed]  
[09:58] <doko_> Riddell: merging libtunepimp
[10:01] <opi> guys, tell me, was there an new XOrg upload?
[10:02] <Burgundavia> opi: what is your issue?
[10:02] <Riddell> doko_: that doesn't need merged, there's a new version out
[10:02] <opi> Burgundavia, it seems to be ABI incompatible with prev version
[10:03] <opi> Burgundavia, my friend is using openChrome drivers I've compiled from thier repos (as Edgy driver didn't work)
[10:03] <doko_> Riddell: ok, please upload :)
[10:03] <Kano> hi
[10:04] <Kano> there is a uck to customize a live iso,but how was it created (from scratch)
[10:04] <opi> Burgundavia, after upgrade hers desktop died and from synopis it looks like a Xorg can't load OC driver
[10:04] <Kano> especially the rootfs
[10:04] <Burgundavia> opi: out of repo drivers are not really our issue, tbh
[10:05] <opi> Burgundavia, yup, I just wanted to confirm if you guys uploaded'em, as I haven't seen this upgrade on my Edgy desktop
[10:05] <Burgundavia> opi: there was a new xorg upload
[10:05] <opi> Burgundavia, no that I blame you :-)
[10:06] <Burgundavia> given I have coded or packaged exactly nothing on Ubuntu, I absolve myself of all responsibility :)
[10:06] <opi> :P
[10:06] <opi> OK, then I'm off to "How to compile video driver against Xorg tree in Ubuntu for females" :>
[10:07] <Burgundavia> opi: is there a reason you need a custom dirver?
[10:07] <opi> Burgundavia, via drivers provided by Eft are dying with "NO SCREEN"
[10:07] <Burgundavia> then that is a bug. Please make certain it is filed
[10:08] <Burgundavia> strong candidate for an SRU, if you can get some good data on it
[10:08] <Mithrandir> Kano: deboosttsrap and apt-get
[10:09] <opi> Burgundavia, and since she's living in Holland I have small amount time to debug it, and OC worked OOTB
[10:09] <opi> Burgundavia, will do, she will be here on XMas and I'll get some time to inspect what's wrong with it
[10:10] <mvo> lifeless: thanks for 74899
[10:12] <lifeless> mvo: np. apport++ :)
[10:13] <lifeless> mvo: also, what do you think of https://launchpad.net/bugs/74747
[10:13] <Ubugtu> Malone bug 74747 in Ubuntu "Default sources.list file has source packages enabled by default" [Undecided,Confirmed]  
[10:13] <pitti> nice bug number :)
[10:13] <doko_> keescook: is the autogen test fix forwarded upstream?
[10:14] <Mithrandir> lifeless: it's a feature in order to comply with the gpl, really.
[10:14] <pitti> hm, but for developers it's nice, and for the spirit of free software too, IMHO
[10:14] <elmo> Mithrandir: that's crack
[10:14] <lifeless> well
[10:14] <elmo> Mithrandir: sources.list has nothing whatsoever to do  with GPL compliance
[10:14] <lifeless> the GPL concept I can see - but having synaptic auto-enable the sources *when requested for source* will achieve that just as well
[10:15] <Mithrandir> elmo: it is?  "Equivalent access" is the wording in the gpl and it's not hard to argue that it should be just as easy to get the source as the binaries.
[10:15] <Burgundavia> pitti: lovely, but 95% of the people pulling down those sources.list don't use it.
[10:15] <lifeless> Mithrandir: you can get to just as easy without downloading gigs of source data over time
[10:15] <elmo> Mithrandir: the sources are on the same server, in the same directory, it doesn't get much more equivalent
[10:16] <infinity> I think most people who aren't RMS agree with elmo on this one.
[10:16] <elmo> Mithrandir: if you want to argue that the GPL enforces equivalence all the way up the stack past simple http/ftp level, I think you're clinically insane
[10:16] <pitti> Burgundavia: *shrug* 95% of the users will download the daily apt-get update lists in vain, too
[10:16] <Mithrandir> elmo: oh, lots of people would argue I'm insane. :-)
[10:16] <pitti> Burgundavia: and sources lists will change very little for stable users
[10:16] <infinity> I did, however, get involved in a flamewar with RMS about this 5 years ago or so, where I took elmo's position, and RMS *insisted* that the GPL required Debian to ship with deb-src lines in sources.list.
[10:16] <lifeless> pitti: not really, as the auto-application of security updates is much more realistically useful.
[10:17] <raphink> it seems indeed that most users need universe more than they need deb-src
[10:17] <infinity> Incidentally, it's the last time I argued with him about anything.  Or spoke to him, for that matter.
[10:17] <pitti> lifeless: (just reductio ad absurdum, sorry)
[10:17] <pitti> Sources.gz for stable/main is so small...
[10:17] <lifeless> well
[10:18] <elmo> pitti:  it may be small but with as many users as we have, each extra pair of HTTP IMS hits hurts
[10:18] <elmo> esp. for security.u.c
[10:18] <pitti> hmkay
[10:18] <pitti> (for the record, 18 kB for dapper-security main)
[10:19] <lifeless> yes, but as elmo notes its 50% of the load on security
[10:20] <pitti> ok, I'm just afraid of those people which will start complaining about 'le huh? apt-get source doesn't work any more in feisty'
[10:20] <mvo> lifeless: apt-setup is responsible for seting up the sources.list. historically it was always including deb-src lines. but I think that the gpl does not really require that it is enable by default
[10:20] <Burgundavia> I am mad or is that 103 GB, assuming 18kb and 6million IPs?
[10:22] <pitti> 'k, the server load argument is pretty compelling to me
[10:23] <Riddell> doko_: any plans for a merge of subversion?
[10:23] <doko_> Riddell: no, infinity wants to merge apache2 first, then subversion
[10:24] <pitti> mvo: if we do that, then IMHO it should become much easier to enable sources; and we have to find a way for non-admins to get source, too
[10:25] <mvo> pitti: easier than going to "repositories" and clicking on "source code"? its two clicks currently 
[10:25] <pitti> mvo: ah, there
[10:26] <mvo> np
[10:26] <Riddell> doko_: right, cool
[10:31] <jdub> pitti: "le huh?" <- awesome
[10:31] <_ion> Btw, couldn't archive.ubuntu.com (or e.g. nearest.archive.ubuntu.com, which would then be used in the default sources.list) be made to return the list of mirrors geographically closest to the client? For example, apt-cache show pdns-backend-geo
[10:34] <mvo> _ion: we have a spec about this for feisty
[10:34] <mvo> :)
[10:34] <dholbach> good morning
[10:36] <_ion> mvo: Ok, i'm reading it now. :-)
[10:38] <dholbach> hey _ion
[10:39] <_ion> Hi dholbach
[10:40] <\sh> moins
[10:40] <Riddell> Keybuk: is anyone processing sync requests?  I've had no response to bug 73152
[10:40] <Ubugtu> Malone bug 73152 in pth "sync pth from unstable" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73152
[10:41] <Mithrandir> Riddell: I am doing it just now.
[10:42] <Keybuk> Riddell: wasn't any point processing them during freeze
[10:42] <Riddell> fair point
[10:43] <Riddell> thanks Mithrandir 
[10:44] <Fujitsu> Mithrandir/Keybuk: Can either of you please let a universe SRU into dapper-updates?
[10:46] <Mithrandir> Fujitsu: has the motu SRU team decided on a policy yet?
[10:46] <Mithrandir> dholbach: ^^
[10:47] <Fujitsu> Mithrandir: It has gone through the process as was decided a number of weeks ago, and been approved by motu-sru.
[10:48] <Mithrandir> Fujitsu: ok, if it has ubuntu-archive subscribed, I'll try to get to it today, then.
[10:49] <Mithrandir> Keybuk: we want people to not drop -Q parameters when calling modprobe, don't we?  (About https://launchpad.net/distros/ubuntu/+source/dmraid/+bug/71980 )
[10:49] <Ubugtu> Malone bug 71980 in dmraid "Please sync dmraid from Debian unstable (main)" [Undecided,Confirmed]  
[10:49] <Fujitsu> Mithrandir: Yep, it's been subscribed for some time now. Thanks!
[10:49] <dholbach> Mithrandir: yeah, they're doing good work already
[10:49] <dholbach> Mithrandir: http://wiki.ubuntu.com/MOTU/SRU and it's linked from StableReleaseUpdates
[10:49] <Mithrandir> dholbach: ok, so the policy is in place.  Great. :-)
[10:49] <Mithrandir> dholbach: yeah, that's fine, but somebody said something about the policy not being finalised yet.
[10:49] <Mithrandir> dholbach: but if it is, that's good.
[10:50] <Keybuk> Mithrandir: right
[10:50] <dholbach> it has been for three or four weeks or something
[10:52] <Mithrandir> Keybuk: thanks.
[10:56] <doko_> dholbach: I'm stuck with just one vote from the SRU team for bug 68380 ...
[10:57] <Ubugtu> Malone bug 68380 in eclipse "eclipse for edgy-updates" [Medium,Confirmed]  http://launchpad.net/bugs/68380
[10:57] <dholbach> doko_: afaik it's either "votes" or "after ... days"
[10:59] <doko_> dholbach: no, I don't see that
[10:59] <dholbach> doko_: "After at least 5 persons have tested the package and attached a "works for me" comment to the bug and after a minimum aging period of 7 days, you may prepare a second upload to release-updates:"
[10:59] <dholbach> oh, hm
[11:00] <doko_> dholbach: I'm still at 1) ... "A proposal is accepted, once three people from the MOTU-SRU team give their assent."
[11:00] <doko_> that's difficult, as the team has just five members
[11:01] <dholbach> doko_: best to ping on the bug again - if you want to ping them privately: StevenK, crimsun, siretart, sistpoty are on the team
[11:04] <doko_> and someone called dholbach ...
[11:05] <dholbach> doko_: somebody called me?
[11:05] <doko_> Mithrandir: (MoM) I requested syncs for libbsf-java and jakarta-log4j1.2
[11:06] <Mithrandir> doko_: there's no point asking on IRC; I'm going by the list of bugs ubuntu-archive is subscribed to.
[11:07] <doko_> Mithrandir: you misunderstand.
[11:07] <Mithrandir> doko_: ok, please explain then
[11:08] <doko_> Mithrandir: going through python and java related MoM entries not assigned to me ...
[11:08] <Mithrandir> doko_: oh, you mean "I stole your libbsf and jakarta-log4j1.2 merges"?  Excellent! :-)
[11:08] <doko_> and these are/were assigned to you.
[11:20] <lifeless> doko_: upload python!
[11:32] <lifeless> doko: so, what do I need to do to get a python2.x upload with the apport hook patch included ?
 doko_: wrt bug 70957, shall I apply the patch myself or do you prefer doing that yourself?
 Malone bug 70957 in python2.5 "support apport reporting for python programs" [Wishlist,Confirmed]  http://launchpad.net/bugs/70957
 pitti: I'm preparing new uploads for python2.4 and python2.5
 doko_: ah, great
[11:32] <Ubugtu> Malone bug 70957 in python2.5 "support apport reporting for python programs" [Wishlist,Confirmed]  http://launchpad.net/bugs/70957
[11:32] <lifeless> sweet
[11:33] <lifeless> thanks!
[11:33] <pitti> heh, I was just going to quote the same
[11:35] <lifeless> gnight y'all
[11:35] <lifeless> small suggestion
[11:35] <mneptok> nighty RC!
[11:35] <lifeless> record such things in the bug reports
[11:35] <lifeless> stops folk needing to read every line of IRC to have a feeling for whats happening
[11:35] <pitti> that should be 'in progress' or 'fixcommitted'
[11:35] <lifeless> tchau!
[11:35] <pitti> lifeless: sleep well!
[11:35] <mneptok> t'pau!
[11:37] <infinity> mneptok: *blink*
[11:40] <seb128> hum, ctrl-left write a "5D" instead of going back one word, is that bash to blame?
[11:41] <mneptok> infinity: Star Trek geekery. sorry. :)
[11:41] <seb128> it worked a few days back
[11:41] <pitti> doesn't work on VT either
[11:41] <seb128> bash has been updated on dec 4th
[11:41] <seb128> I blame it
[11:41] <seb128> dooookooooooo
[11:42] <pitti> oh, bash doesn't use libreadline5?
[11:42] <pitti> oh, ncurses
[11:43] <pitti> doko, seb128: confirmed, downgrading bash to edgy makes it work again, so it's not ncurses or libreadline
[11:44] <seb128> ok
[11:44] <StevenK> mneptok: Which uses zle ...
[11:44] <mneptok> yup
[11:45] <doko> pitti: bash uses the statically linked libreadline for performance reasons
[11:45] <pitti> oh, argh
[11:45] <pitti> doko: ok, so I suspect it's rather a bug in readline
[11:46] <pitti> hm, that hasn't been updated since October
[11:46] <pitti> but might have been synced just recently
[11:47] <pitti> doko: that's only startup performance? or do they have any patches to it?
[11:48] <doko> pitti: yes, startup performance
[11:48] <pitti> I see (although with our /bin/sh being dash now, it won't make much of a difference any more)
[11:50] <Keybuk> about 2,000 lines into the unit tests, I was clearly losing the will to live
[11:50] <pitti> Keybuk: *being curious*
[11:51] <Keybuk>  * everything we do and must live a fully moral and selfless life to avoid
[11:51] <Keybuk>  * the eternal misery that awaits us.
[11:51] <Keybuk>  *
[11:51] <Keybuk>  * The alternative is that we just die, and so does everyone else, so
[11:51] <Keybuk>  * everything we ever do is ultimately forgotten and therefore meaningless.
[11:51] <Keybuk>  *
[11:51] <Keybuk>  * Oh, yeah, check the return value was what we expected, or something.
[11:51] <Keybuk>  */
[11:51] <Keybuk> /* If there's a god, and eternal life, then we're all held accountable for
[11:52] <Keybuk> (first line got eaten by IRC there, oops)
[11:56] <Riddell> pitti: any plans for main inclusion queue reviews soon?  I've a bunch pending
[11:57] <pitti> Riddell: right, I saw the wiki mails, and the amount scared me
[11:57] <pitti> Riddell: can't promise that I'll manage today, but on Tuesday at most
[11:58] <Riddell> you should finish your gnome-mount patch first of course :)
[11:58] <pitti> hehe
[11:58] <pitti> oooh, btw, exactly the right man and right topic
[11:58] <pitti> Riddell: does KDE pay attention to volume.ignore?
[11:58] <pitti> Riddell: I'm implementing https://wiki.ubuntu.com/MountAllLocalFilesystems ATM
[11:58] <Riddell> pitti: don't have a clue, what does it mean?
[11:59] <pitti> Riddell: if KDE would suddenly display icons for fixed unmounted HD partitions, but you cannot mount them through the UI, we need to figure out something
[11:59] <pitti> Riddell: gnome-vfs interprets it as 'show an icon for the volume' (false) or 'don't bother the user with that one' (true)
[12:00] <pitti> Riddell: so far we had volume.ignore for nonremovable volumes
[12:00] <pitti> (== true)
[12:00] <Mithrandir> seb128,dholbach: can one of you ACK or NACK https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bug/74416 please?
[12:00] <Ubugtu> Malone bug 74416 in gnome-backgrounds "Please sync gnome-backgrounds (universe) from unstable (main)" [Undecided,Confirmed]  
[12:00] <doko> Mithrandir: I don't understand your last comment for bug 74613
[12:00] <Ubugtu> Malone bug 74613 in python-setuptools "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74613
[12:01] <dholbach> Mithrandir: I think seb128 worked with xerxas on it, so it should be fine.
[12:01] <Mithrandir> doko: there's no copy of debian/changelog from when the Ubuntu package branched off until what you're asking to be synced.
[12:02] <doko> Mithrandir: ahh, ok thought that was the icu thing
[12:02] <seb128> Mithrandir: ack
[12:02] <Mithrandir> doko: I've commented about the same on multiple bugs today; it would simplify my job if you used the requestsync script (or emulated its output)
[12:02] <seb128> Mithrandir: I've commented on the bug
[12:02] <Riddell> pitti: I'm told KDE does respect volume.ignore
[12:02] <Mithrandir> seb128: thanks.
[12:02] <seb128> np
[12:03] <pitti> Riddell: ok, can we continue in 30 mins or so? I'm off for lunch
[12:03] <doko> Mithrandir: what is the rationale for including the changelog? I.e. it's incomplete anyway if we sync a new upstream version
[12:03] <Riddell> pitti: sure
[12:03] <iwj> Keybuk: This `watershed' command doesn't exist yet, right ?  So I should go and write it.
[12:03] <Mithrandir> doko: it makes it possible for me to check that the changes you say are included actually are documented as included, for instance?
[12:04] <Keybuk> iwj: it does, it's just not in the feisty package yet because I hadn't got to it yet
[12:04] <iwj> Oh.
[12:04] <Keybuk> just leave it out for now, for testing purposes without it is good enough
[12:04] <Keybuk> it's a built-in thing
[12:04] <iwj> Err, right.
[12:04] <doko> Mithrandir: no, not if things are changed/integrated upstream
[12:05] <Mithrandir> doko: if you want to change the policy of what information we want, you're free to do that on ubuntu-devel@lists, but until a change occurs, this is the policy which is in place.
[12:05] <iwj> Keybuk: Also, I wanted to talk to you about this alleged race which means we supposedly have to move the symlink creation from vgchange to a vgmknodes run by udev.
[12:05] <Keybuk> iwj: yes
[12:06] <iwj> In fact it is sufficient to run vgmknodes, and there is no need to change vgchange.
[12:06] <iwj> Because vgmknodes takes out the vg lock as does vgchange, so vgmknodes does nothing but cannot exit until vgchange has finished.
[12:07] <Keybuk> ok
[12:07] <Keybuk> that's sufficient
[12:07] <iwj> I did have to fix the way the symlinks were dealt with to stop it doing unlink();symlink() and make it do symlink();rename() instead.
[12:07] <Keybuk> it's basically just so that later RUN rules in the processing of the resulting devmapper block devices can rely on the /dev/VG/LV symlinks existing, as well as /dev/mapper/VG-LV
[12:07] <iwj> Right.  I just wanted to check that the race you were thinking of was that the udev event for the dm device might be processed with the link not present.
[12:07] <iwj> Right.
[12:07] <Keybuk> yes
[12:08] <Keybuk> it would be nice if udev could say "I have this new devmapper block device, it's dm-0, but really /dev/mapper/VG-LV ... and it's LVM, so also /dev/VG/LV"
[12:08] <Keybuk> thus it'd work whatever people put in their fstab, etc.
[12:08] <iwj> OK.  I'll tidy the lvm2 changes up and upload them.
[12:08] <Keybuk> cool
[12:08] <Keybuk> thanks
[12:08] <iwj> Right.
[12:09] <iwj> The extra udev rule (in the lvm2 package) is harmless if you remove-but-not-purge lvm2 AFAICT.
[12:09] <iwj> Do you want me to do the vgmknodes or are you going to call that ?  And are RUN rules done sequentially ?
[12:09] <Keybuk> "extra udev rule" ?
[12:10] <iwj> UBSYSTEM=="block", RUN+="watershed /sbin/vgchange ....
[12:10] <Keybuk> the vgmknodes rule should be shipped by lvm2 as well
[12:10] <Keybuk> RUN rules are done in sequence for a particular job, yes
[12:10] <iwj> shipped by lvm2> Right.  With a lowish priority so it happens early.  Right.
[12:11] <Keybuk> 85-*.rules
[12:11] <Keybuk> maybe 82-*.rules given it's for a race checking
[12:11] <iwj> Right, exactly, that's what I meant.
[12:12] <iwj> Err, in fact, thinking about it, the dm device itself will case vgchange to run again so that's just as good as vgmknodes.
[12:12] <iwj> s/ case/ cause/
[12:13] <Keybuk> shiny
[12:18] <Keybuk> pitti: talking of which, I'd like to move the hal udev rules
[12:19] <Keybuk> I think it'd make more sense for it to be 95-hal.rules not 85, as it's being run before udev has really finished
[12:32] <Keybuk> Riddell: tagcoll vs. tagcoll2
[12:32] <Keybuk> you requested the latter be sync'd from Debian
[12:32] <Keybuk> should we remove and blacklist the former?
[12:32] <Riddell> Keybuk: yes please
[12:32] <Keybuk> why hasn't tagcoll been removed from Debian?
[12:33] <Riddell> the source package has as far as I can see, the binary tagcoll package now comes from tagcoll2
[12:33] <Riddell> oh, except 1.6.3-1: kfreebsd-i386
[12:34] <Keybuk> oh, fair enough
[12:35] <infinity> Oh sure, he leaves like 30 seconds before I wanted to ask him something.
[12:36] <StevenK> infinity: Just so you can have the pleasure of waiting for him. Duh.
[12:36] <infinity> Damn Seb, always playing hard to get.
[12:36] <mneptok> infinity: "yes, i'm wearing them. did you get the .jpgs?"
[12:36] <infinity> StevenK: Feel like being a good samaritan and debugging why the e-d-s build SEGVs on ia64? *bat lashes*
[12:37] <infinity> (And I don't want to hear "I don't have an ia64 box" as an excuse either, young man)
[12:38] <StevenK> infinity: I wasn't actually going to say that, it was more along the lines, "I don't have an account on an ia64 box that I can install build-deps on." :-)
[12:39] <Keybuk> Riddell: libapt-front will need changing build-deps
[12:39] <Keybuk> as well tagcolledit
[12:39] <Riddell> Keybuk: libapt-front has been renamed to libept (which should be in NEW)
[12:39] <Riddell> tagcolledit I'll fix
[12:39] <Keybuk> "ept" ?!  has lifeless been naming our packages? :p
[12:40] <StevenK> libept fails to build due to no tagcoll2, from what I recall.
[12:40] <Keybuk> StevenK: ah, we appear to have reached the middle of this conversation
[12:41] <StevenK> I'm trying to say it isn't in NEW, it's in the archive, it just hasn't built.
[12:41] <StevenK> infinity: I'm happy to do so, if you want.
[12:41] <cjwatson> Keybuk: one thing that occurred to me when reading udev-lvm and udev-evms in parallel: presumably you either want some option to watershed to tell it where its lock file is, or for it to work that out dynamically based on the command name?
[12:41] <Keybuk> cjwatson: the one in udev is done on the rule name
[12:41] <Keybuk> but I was thinking of doing it in upstart instead
[12:42] <cjwatson> "rule name"?
[12:42] <Riddell> StevenK: so it is, that means Keybuk can throw out libapt-front
[12:42] <Keybuk> cjwatson: it's a function in udev, if the RUN+= begins "watershed" it's done inside udev based on the rule id in the parsed table
[12:42] <cjwatson> oh, I see
[12:42] <cjwatson> cute
[12:42] <infinity> StevenK: Would be awesome, if you have access to the hardware.  If not, I'll have to bug someone on staff to do it, or do it myself when I have time.
[12:42] <infinity> StevenK: Someone like seb!
[12:43] <StevenK> infinity: ... Ubuntu has ia64 machines. :-P
[12:43] <infinity> seb128: If I bake you cookies, will you debug the e-d-s segv on ia64?
[12:43] <infinity> StevenK: Not publically accessible (yet), unfortunately. :/
[12:43] <StevenK> I have this small feeling that my wife would object to my buying an ia64 on a credit card just so infinity will love me.
[12:44] <Riddell> enrico: tagcolledit build-deps should be changed in debian too no?
[12:44] <seb128> infinity: I'll have a look
[12:44] <seb128> infinity: hum, e-d-s segfault or e-d-s 1.9.3 build failure?
[12:45] <infinity> seb128: The build failure, if you look carefully, looks suspiciously like a segv in the build.
[12:46] <seb128> infinity: bah, looks like gtk-doc not being happy with amd64, glade-3 was already failing on documentation build
[12:46] <infinity> s/amd64/ia64/
[12:46] <seb128> right
[12:47] <Riddell> enrico: actually it doesn't compile, any plans for a tagcolledit for libtagcoll2?
[12:47] <seb128> infinity: I think I'll be lazy and upload a version without --enable-gtk-doc, that's not required, the tarball ships the html files
[12:47] <infinity> seb128: Laziness works for me.
[12:47] <infinity> seb128: I can't really ask you to spend any paid time on ports anyway, so whichever lazy route you prefer. :)
[12:48] <seb128> ok ;)
[12:49] <seb128> could anybody get evolution out of NEW?
[12:49] <infinity> seb128: I already did.
[12:49] <seb128> excellent
[12:53] <cjwatson> pitti: I have a tiny hal patch which makes it work better with mouseemu; just makes probe-input.c allow the BUS_VIRTUAL type
[12:53] <cjwatson> pitti: mind if I upload, or should I file a bug?
[12:53] <mjg59> Hm. I thought we had that already.
[12:55] <pitti> Keybuk: argh @ conffile transition, but fine for me
[12:56] <cjwatson> mjg59: apparently not
[12:56] <pitti> cjwatson: since I need to upload a new hal for Keybuk anyway, maybe just commit the patch into the bzr?
[12:56] <cjwatson> also need to figure out how to make gnome-power-manager notice new keyboards appearing in hal
[12:56] <cjwatson> pitti: ah, I didn't check bzr; will do
[12:56] <pitti> cjwatson: sftp://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu
[12:57] <pitti> cjwatson: if that's fine for you?
[12:57] <cjwatson> thanks
[12:57] <cjwatson> sure
[12:57] <infinity> seb128: Hrm, if it's gtk-doc hating life, I suppose we could wait for the newly-synced source to build and retry e-d-s to see if it's magically happy again.
[12:57] <pitti> cjwatson: I'll do Scott's conffile transition this afternoon then, and upload
[12:57] <seb128> infinity: seems a good idea to me
[12:57] <seb128> let's do that ;)
[12:57] <infinity> seb128: Alright, I'll let you know if it remains FUBAR.
[12:57] <seb128> thank you
[12:57] <cjwatson> I'll fix up the udev rule installation in mouseemu
[12:58] <cjwatson> Keybuk: where should a rule to restart a program on add events go? 80?
[12:58] <pitti> Riddell: so basically you need to decide whether or not you want to handle mounting of fixed non-auto-fstab hard disk partitions in KDE
[12:58] <Keybuk> cjwatson: 85
[12:58] <pitti> Riddell: if so, then you can just use the new hal and need a similar trick in KDE that I do in gnome-mount (if you get a permission error, sudo yourself as root again)
[12:59] <Riddell> pitti: it would be nice, it's kindae a mess at the moment
[12:59] <cjwatson> oh yes, reading ALL of /etc/udev/rules.d/README helps
[12:59] <pitti> Riddell: if not, then we need to modify the hal fdi rules or kio's interpretation of it to not show them
[01:00] <Riddell> pitti: sudo again?  is it already sudoed?
[01:00] <pitti> Riddell: (gksu in the gnome case, some kdesu GUI wrapper for you)
[01:01] <pitti> Riddell: the current gnome-mount approach is: try as user, if you get a PermissionDeniedByPolicy error, try 'gksu -- gnome-mount ...'
[01:01] <pitti> Riddell: for admin members, that is
[01:01] <pitti> Riddell: so that admins can mount them through the UI, and non-admins don't
[01:02] <Riddell> pitti: clever
[01:02] <Riddell> pitti: does gnome-mount replace pmount?
[01:02] <pitti> Riddell: over three corners, yes
[01:03] <pitti> Riddell: the hal mounting backend replaces pmount
[01:03] <pitti> and gnome-mount calls it
[01:11] <rodarvus> slomo: pong
[01:12] <Fujitsu> infinity: Apparently I kick you to get the maintainer field unclobbered for my packages.
[01:12] <infinity> Fujitsu: Indeed.
[01:12] <infinity> Fujitsu: Or pitti, I suppose.
[01:13] <slomo> rodarvus: will you merge/update the xorg stuff? if so it would probably nice to include one patch from upstream for the ati driver that is in no release :) shall i file a bug for this or is just giving you the changeset/diff enough?
[01:13] <infinity> Fujitsu: Specific packages, specific email you want whitelisted, what?
[01:13] <Fujitsu> infinity: You're significantly closer for kicking :P
[01:13] <rodarvus> slomo: yes, this is enough, please do
[01:13] <Fujitsu> infinity: Specific email, if you please.
[01:13] <rodarvus> (and assign the bug to me)
[01:14] <slomo> rodarvus: will do, thanks (changeset 9f5ea3981449f29ff204eb154166e8fc813205fa btw)
[01:14] <infinity> Fujitsu: Given our proximity, I may expect bribery.  pitti wouldn't ask you to hand-deliver a souvlaki from Lamb on Chapel.
[01:14] <Fujitsu> Hahahahha
[01:15] <StevenK> Like Fujitsu is old enough to drive.
[01:16] <infinity> That doesn't work.
[01:16] <infinity> Anyhow.
[01:16] <infinity> Fujitsu: Which email do you need whitelisted?
[01:16] <Fujitsu> (after catching the train, and abducting infinity) So there!
[01:16] <Fujitsu> infinity: william.grant@ubuntu.com.au
[01:16] <infinity> Fujitsu: And don't you have an ubuntu.com email?
[01:16] <infinity> Fujitsu: And if so, why not just use that?
[01:16] <infinity> (All ubuntu.com is whitelisted)
[01:16] <Fujitsu> Hahah, that's bug... I forget which.
[01:17] <Fujitsu> I don't have an ubuntu.com address, because of some bug because my primary address has ubuntu.com in it.
[01:17] <infinity> Cute.
[01:17] <StevenK> Ohhhh. Neat.
[01:17] <infinity> Fujitsu: Do we have other people at ubuntu.com.au?  Should I just whitelist the domain?
[01:18] <StevenK> Personally, I'd prefer to have my @ubuntu.com be my primary address in Launchpad.
[01:18] <Fujitsu> I'm the only one with packages at the moment.
[01:18] <StevenK> I've heard "don't do that", however.
[01:18] <siretart> infinity: did we or rather team soyuz import the pre-soyuz katie whitelist into soyuz?
[01:18] <Fujitsu> Yeah, bug 62109 is why I don't use @ubuntu.com.
[01:18] <Ubugtu> Malone bug 62109 in launchpad "ubuntu.com email address creation" [Low,Confirmed]  http://launchpad.net/bugs/62109
[01:18] <infinity> siretart: This is an entirely different whitelist.  katie never did what I'm doing now (overwrite maintainer fields in binary builds)
[01:19] <siretart> ok
[01:19] <infinity> StevenK: The current system forwards your lpaccount@ubuntu.com to your primary address, and we don't like mail loops.
[01:20] <infinity> StevenK: I'm sure it could be made smarter to pick the secondary if the primary would be an obvious loop, but whatever.  Social solutions are easier than code sometimes.
[01:20] <Fujitsu> Which is exactly why mine doesn't exist yet.
[01:20] <Fujitsu> Somebody forgot a $, I suspect :P
[01:21] <StevenK> infinity: But it's like two lines of code, surely?
[01:21] <infinity> StevenK: Not my code, don't know.  I try to avoid touching too much launchpad code, lest someone suggest I move to the launchpad team.
[01:21] <StevenK> Heh
[01:23] <infinity> Oh, piss off apt, you filthy... ARGH.
[01:23] <infinity> Can someone hit Michael for me when he logs on again?  kthx.
[01:23] <infinity> E: Could not open file /var/lib/apt/lists/ftp.iinet.net.au_linux_ubuntu_dists_feisty_universe_source_Sources - open (2 No such file or directory)
[01:23] <StevenK> Heh
[01:24] <infinity> That is NOT a valid reason to refuse to let me apt-get source from main.
[01:24] <infinity> And running "apt-get update" on a 512k line is painful.
[01:24] <Fujitsu> Ah, but it is.
[01:24] <StevenK> infinity: 50KB/s is too slow?
[01:24] <infinity> StevenK: For a man used to 24Mbps at home, yes, it's too effin' slow.
[01:25] <StevenK> infinity: I invite you to remember Australia bandwidth, say even 4 years ago.
[01:25] <infinity> StevenK: I've only lived here for 3.
[01:25] <StevenK> Yes, exactly.
[01:25] <infinity> StevenK: And I started with 1.5Mbps when I moved here.  Which *was* painful too, but not as bad as this.
[01:26] <StevenK> Fujitsu: My carrier is Exetel. It's hard to forget.
[01:26] <StevenK> infinity: I'm on 1.5 at the moment, trying to decide if I can swing a switch to ADSL2+
[01:26] <infinity> StevenK: I rather like my ADSL2+
[01:27] <StevenK> I'm getting that impression. :-)
[01:27] <infinity> StevenK: Was  abit shaky when it was first connected, now it's solid, fast, and quite nice.
[01:29] <StevenK> infinity: My main concern is what to do with my mail for 5-8 days while I get disconnected/reconnected.
[01:30] <infinity> StevenK: Ask some kind soul like me to be a backup MX and spool it all for you?
[01:30] <StevenK> Or get work to do it.
[01:30] <infinity> Indeed.
[01:32] <StevenK> It's also the question of a spare $250. Which around Christmas doesn't exist.
[01:36] <infinity> Fujitsu: https://lists.ubuntu.com/archives/feisty-changes/2006-December/001980.html
[01:37] <Fujitsu> Thanks, infinity.
[01:38] <infinity> Soon, I hope.  I;'m starving.
[01:38] <StevenK> deliver, even
[01:39] <infinity> Fujitsu: A number 3, please (the L.O.C special)
[01:39] <cjwatson> infinity: oh, please whitelist cjwatson@debian.org maintainer fields. kind of a shame it doesn't notice any LP people who have an @ubuntu.com address, and whitelist all of their validatedemail addresses?
[01:39] <infinity> Fujitsu: A side of saganaki too.
[01:39] <Fujitsu> cjwatson: That'd be a good idea.
[01:39] <infinity> cjwatson: Want it whitelisted, or overridden to cjwatson@ubuntu.com?
[01:40] <cjwatson> infinity: just whitelisted is fine; is a different hat
[01:40] <infinity> cjwatson: Fair 'nuff.
[01:40] <cjwatson> Fujitsu: I actually assumed it worked that way until I checked man-db just now
[01:41] <cjwatson> infinity: any way to make this configuration on the buildds rather than requiring an upload?
[01:41] <infinity> cjwatson: It has no LP knowlege whatsoever.  File a bug on launchpad-buildd if you'd like the functionality more integrated, though.  I could waste some cycles on it sometime.
[01:41] <infinity> cjwatson: Oh, I can change the config in the chroots, but it's easier to just upload.  *shrug*
[01:41] <infinity> cjwatson: With the exception of today, people don't exactly ask often. :)
[01:42] <cjwatson> bug> will do
[01:44] <verwilst> Mithrandir: ping
[01:45] <infinity> cjwatson: Mangled.
[01:46] <cjwatson> ta
[01:47] <infinity> seb128: Err, wait... gtk-doc is arch:all... How can it hate one arch more than another? :)
[01:48] <Fujitsu> How often is MoM meant to update? I uploaded matplotlib 15 hours ago, it still hasn't updated to reflect said upload.
[01:48] <infinity> seb128: I'd assume it's a jade bug or something.
[01:49] <StevenK> jade, on the other hand, hates all arches equally.
[01:50] <seb128> infinity: good remark, yeah, probably
[01:51] <infinity> StevenK: I remember it being more often broken than not on many in the past, yes.
[01:51] <infinity> StevenK: Not the world's happiest codebase.
[01:51] <StevenK> Yeah, well.
[01:55] <cjwatson> infinity: launchpad-buildd has no open bugs - is it definitely the right product?
[01:58] <Mithrandir> verwilst: please include some context with your ping.
[01:58] <verwilst> Mithrandir: one context, coming up :p
[01:59] <verwilst> Mithrandir: i just noticed the grub2 spec in the wiki
[01:59] <verwilst> Mithrandir: is it still on track for feisty? the grub2 site seems pretty scarse with updates/status reports :)
[02:00] <Mithrandir> verwilst: I haven't yet started actually working on it, just poking it a bit with a stick.
[02:00] <Mithrandir> verwilst: I'm intending to have it ready for feisty, yes.
[02:00] <verwilst> Mithrandir: sweet :)
[02:01] <Mithrandir> verwilst: it won't be default for i386/amd64/ppc, but it should be available in expert mode at least.
[02:01] <verwilst> Mithrandir: it supports EFI too eh
[02:01] <verwilst> the wiki says it doesn't
[02:02] <cjwatson> the status reports are inconsistent
[02:02] <verwilst> "It is working on PC, OpenFirmware-based PowerPC machines (PowerMac and Pegasos) and EFI-based PC (IntelMac)"
[02:02] <verwilst> so at least it means they're still actively coding it :)
[02:02] <infinity> cjwatson: It used to be the right product.  cprov may have moved everything to "soyuz" with tags...
[02:03] <cjwatson> EFI support is one reason we're pushing for it, for the Intel Macs
[02:03] <Mithrandir> cjwatson: well, according to mjg59 not doing bootcamp on intel macs is going to just be really painful.   We might want to go that route anyway, though.
[02:03] <cjwatson> oh, yeah, true
[02:04] <cjwatson> but even then it's going to be better than lilo, and our grub doesn't do intel-macs-with-bootcamp at the moment
[02:04] <Mithrandir> yeah, true
[02:04] <infinity> cjwatson: Yeah, file it on soyuz, and tag it "soyuz-build", I guess.
[02:04] <cjwatson> oh, damn, that's a point, I need to make mouseemu work on intel macs without visible EFI
[02:05] <cjwatson> was hoping not to have to shell out to dmidecode
[02:05] <verwilst> and maybe grub2 will have support for xfs and such?
[02:05] <verwilst> so i can finally get rid of my ext3 /boot's ;)
[02:05] <Mithrandir> grub 1 supports xfs, afaik.
[02:06] <Mithrandir> it just requires xfs_freeze to be run
[02:06] <verwilst> Mithrandir: myeah it does.. but not enabled in ubuntu i think?
[02:06] <verwilst> oh?
[02:08] <verwilst> ReiserFS and graphics-based user interface are still pending items
[02:08] <cjwatson> Mithrandir: that isn't enough
[02:08] <verwilst> 2 nice things :p
[02:08] <cjwatson> I've tested this extensively in the past, and briefly recently
[02:08] <cjwatson> they've always *claimed* it supports xfs that way, but it doesn't actually work - there's still a fairly wide race condition
[02:09] <Mithrandir> cjwatson: ok.
[02:09] <verwilst> cjwatson: maybe grub2 brings some relief ;)
[02:09] <cjwatson> I don't know the situation with grub2 there. To be honest I think it's an XFS bug.
[02:09] <cjwatson> but maybe grub2 manages to work around it somehow
[02:11] <mjg59> xfs has different ideas about when data actually hits the disk
[02:11] <mjg59> Which makes it harder to guarantee that your bootloader is going to be able to find it
[02:14] <cjwatson> yes, well, I have little sympathy for folks who think pushing the uttermost limits of POSIX is a fun game
[02:15] <cjwatson> it's technically allowed, but manages to be less useful than all the other filesystems, so ...
[02:18] <cjwatson> the only real answer I've seen with grub1 is to queue actual grub installation until /target is unmounted, which requires a load more stuff in udebs and has suboptimal consequences for error recovery
[02:18] <cjwatson> or just to stick a sleep 60 in there, which makes me a sad panda
[02:19] <verwilst> cjwatson: can't you just sync it or something?
[02:19] <cjwatson> verwilst: doesn't work, hence my POSIX comment above
[02:19] <verwilst> oh
[02:19] <cjwatson> XFS reads the sync spec *very* carefully indeed and does about as little as it can get away with - which isn't enough to let grub actually read the data back
[02:20] <verwilst> cjwatson: hm
[02:20] <verwilst> and there's no way to force it to do some more? ;)
[02:21] <cjwatson> you have to actually unmount the filesystem (or maybe remount it read-only) to force it, and that's logistically very difficult at that stage in the installer, considering that we're running the grub binary from the same filesystem and have other stuff mounted in there
[02:21] <cjwatson> no other method that's been suggested has worked in my tests
[02:21] <verwilst> bleh
[02:21] <cjwatson> you may find it works on some machines - it's a race condition, so that's to be expected
[02:22] <cjwatson> and sleeping for a minute or so and trying again probably works, but is very unsatisfactory
[02:29] <cjwatson> meh, where did the dpkg.org A record go??
[02:29] <cjwatson> s/\?//
[02:30] <doko> cjwatson, Mithrandir, mdz: who can/wants to comment/approve feistyplusone-toolchain-roadmap ?
[02:31] <pitti_> cjwatson: oh, I already seriously doubted my memory when I looked for it some days ago...
[02:32] <pitti_> eventually I found the stuff on wiki.debian.net
[02:32] <cjwatson> pitti_: thanks, that'll do
[02:32] <cjwatson> doko: probably not me just now
[02:36] <pitti_> bhbh bh bh f 
[02:36] <pitti_> argh
[02:37] <pitti_> wow, that's a pretty amazing pattern it managed to produce while jumping on the keyboard
[02:40] <_ion> im on ur laptop, developin ur ubuntu
[02:41] <cjwatson> pitti_: that was almost Irish
[02:41] <cjwatson> "vvvvv", basically ;)
[02:43] <_ion> I'd pronounce it "bhbhbhbhf", not "vvvvv". :-)
[02:43] <pitti_> _ion: the cat probably disagrees
[02:49] <pitti_> doko: btw, you know about requestsync? (wrt. changelogs)
[02:50] <doko> pitti_: yes, but that doesn't solve the problem
[02:51] <pitti_> yup, just wanted to make sure that you don't file requests manually
[03:03] <Q-FUNK> it seems that Planner requires an explicit Build-Depends on libdbus-glib-1-dev to build on Ubuntu.  I'll just add it and re-upload to Debian.
[03:04] <pitti_> Q-FUNK: maybe some later gtk/whatever dropped it? then it might sooner or later bite Debian, too, right
[03:04] <pitti_> Q-FUNK: hello, bte
[03:04] <pitti_> btw
[03:05] <Q-FUNK> :)
[03:05] <Q-FUNK> I guess it would be a good idea for me to update my ubuntu chroot to feisty and test this before uploading... :)
[03:06] <pitti_> heh
[03:07] <seb128> Q-FUNK: that was a transitional bug, time to get some packages rebuilt with the new gnome-vfs, that's fixed now
[03:07] <pitti_> erm, praises
[03:07] <pitti_> argh @ my English brain cells today
[03:07] <seb128> pitti_: you want to take over X? ;)
[03:08] <cjwatson> pitti_: either works
[03:08] <Q-FUNK> seb128: come again?  would simply re-launching the builds at ubuntu fix it or do I need to update my "upstream" debian package for anything?
[03:08] <cjwatson> although the latter is slightly better
[03:08] <pitti_> cjwatson: oh? I thought I mixed it up with 'Uhura, hail the Klingons'
[03:08] <seb128> Q-FUNK: retry a build should work, if not there is some package still shipping a .la mentioning the lib which should not
[03:09] <seb128> Q-FUNK: common GNOME libs have been rebuilt, planner might use a "non-common" lib that needs a rebuild too though
[03:09] <Q-FUNK> seb128: ok.  can you relaunch those or who should I ask?
[03:09] <seb128> just ask on the chan if somebody can give a retry to the planner build
[03:09] <seb128> some people can do that
[03:10] <seb128> infinity, Keybuk
[03:10] <Q-FUNK> ok
[03:10] <seb128> hey infinity ;)
[03:11] <Q-FUNK> speaking for the devil^Wangel.
[03:11] <infinity> planner given-back.
[03:11] <Q-FUNK> thanks!
[03:12] <infinity> seb128: For the record, you should recommend me or Mithrandir for give-backs.  Keybuk's more of a last resort. :)
[03:12] <infinity> seb128: I'll be working on proper docs and ways to contact the buildd team and sending some stuff to -devel-announce in he next week, though.
[03:12] <seb128> infinity: ok ;)
[03:14] <cjwatson> pitti_: the word has both meaning
[03:14] <cjwatson> s
[03:14] <Keybuk> in fact, I always ignore any requests for buildd work if either infinity or Mithrandir are around
[03:14] <Keybuk> I only have the power in case either is hit by a bus
[03:14] <Keybuk> *honk*honk*
[03:16] <Q-FUNK> if they get hit by dbus, does it count? ;)
[03:18] <infinity> If people make nerd jokes and are subsequently hit by a real bus, do we care? :P
[03:19] <Keybuk> it could be worse; one could get hit by the VESA Local Bus
[03:19] <Mithrandir> I'm not sure whether VLB is better or worse than the PCI Express
[03:19] <infinity> Die.  All of you.  Seriously.
[03:19] <Mithrandir> You can get overrun in 16 lanes.  At once!
[03:20] <thom> i hate geek humour.
[03:20] <thom> "humour"
[03:20] <Mithrandir> it's friday afternoon, I'm sorry. :-P
[03:20] <infinity> thom: And this is why we get along.
[03:22] <Q-FUNK> how about a nice game of dbus frogger?
[03:22] <thom> Q-FUNK: how about a nice cup of...
[03:23] <Q-FUNK> thom: smile!  you're on candid camera! :-P
[03:32] <Mithrandir> uh, is malone really, really broken right now?
[03:32] <Mithrandir> ah, no
[03:34] <Q-FUNK> infinity: it seems that the takeback on planner worked. thanks!
[03:35] <infinity> Q-FUNK: NP.
[03:37] <enrico> Riddell: oh, right, tagcolledit!  Glad you mentioned
[03:38] <enrico> Riddell: it should build with tagcoll (not tagcoll2), does it not?
[03:46] <Mirv> pitti: hi, about your debian bug 402145. the package does generate different files for low/big-endian systems, should it still be Arch:all?
[03:46] <Ubugtu> Debian bug 402145 in voikko-fi "voikko-fi: package should be arch:all" [Unknown,Open]  http://bugs.debian.org/402145
[03:47] <wasabi__> Welp, 2.6.19 doesn't even seem to see this CD drive
[03:47] <wasabi__> alas
[03:51] <bddebian> Howdy
[03:53] <Riddell> enrico: well the configure check fails at least
[03:54] <Riddell> checking for LIBTAGCOLL... configure: error: Package requirements (libtagcoll) were not met:
[03:54] <Riddell> No package 'libtagcoll' found
[03:55] <cjwatson> ogra_,pitti: any ideas on the gnome-power-manager side of bug 67954?
[03:55] <Ubugtu> Malone bug 67954 in mouseemu "mouseemu prevents detection of Power button event" [Unknown,Unconfirmed]  http://launchpad.net/bugs/67954
[03:55] <Riddell> enrico: and changing aclocal to accept libtagcoll2 the include's are a problm
[03:55] <Riddell> enrico: CommandlineParser.cc:22:29: error: tagcoll/stringf.h: No such file or directory
[04:00] <pitti> Mirv: oh, does it? they had exactly the same size and looked quite arch:all to me; sorry if that's wrong, I'll just close the bug then
[04:01] <enrico> Riddell: yes.  It should build with libtagcoll-dev, it surely won't build with libtagcoll2-dev
[04:01] <pitti> Mirv: oh, and thanks for the reports and caring for a good Finnish support
[04:01] <pitti> cjwatson: will look in a minute
[04:01] <enrico> I can  try to port it to tagcoll2 now, but that'd be quite late for etch
[04:02] <Mirv> pitti: http://packages.debian.org/testing/text/voikko-fi <- it is different for hppa/m68k/mips/powerpc/s390/sparc than the rest
[04:02] <Mirv> pitti: thanks for having good instructions on how to proceed :)
[04:02] <enrico> Riddell: I'll try to make it work with tagcoll
[04:03] <elmo> pitti: if that's an ispell thing, they are indeed endian-specific
[04:04] <pitti> elmo: no, these are rules files for a system called 'malaga'
[04:04] <cjwatson> pitti: actually, I might be able to figure this out ...
[04:04] <Riddell> enrico: oh, so libtagcoll-dev is staying in the archive?
[04:04] <pitti> cjwatson: I don't have mouseemu installed on my system (we don't install it by default)
[04:04] <cjwatson> pitti: correct, not yet :-)
[04:04] <Riddell> enrico: why not just port tagcolledit and scrap the old tagcoll?
[04:04] <pitti> cjwatson: apparently because this guy has an x86 macbooc
[04:04] <enrico> Riddell: yes, it does, because of apt-front
[04:04] <cjwatson> pitti: we're going to need to for >1 button mouse support on intel macs
[04:04] <pitti> right, I figured
[04:05] <enrico> Riddell: unfortunately, adept hasn't been ported to ept yet
[04:05] <cjwatson> hence I'm trying to make it work, since intel-mac-support is one of mine
[04:05] <enrico> Riddell: it requires libapt-front, which requires tagcoll 1
[04:05] <enrico> Riddell: I'd really like to get rid of tagcoll 1 and apt-front
[04:05] <cjwatson> pitti: I think I just need to add a device-added signal in gpm-hal-monitor.c
[04:07] <Mirv> pitti: they are different files (_b and _l) with different contents, but presumably the upstream could make it unneeded at some point. but apparently the libvoikko currently needs them in that way, different byte-order for different endianness
[04:07] <Riddell> enrico: this is a tangled web of dependencies
[04:08] <ogra_> cjwatson, that signal should be there already
[04:09] <pitti> Mirv: I closed the bug; sorry for the noise
[04:09] <ogra_> cjwatson, there is power_button_pressed in src/gpm-manager.c in the gpm source
[04:09] <ogra_> it gets the event from hal though
[04:10] <cjwatson> ogra_: it doesn't notice when new keyboards appear, which is device_added
[04:10] <cjwatson> ogra_: this is actually a real problem :-)
[04:10] <ogra_> does hal notice it ?
[04:10] <cjwatson> ogra_: mouseemu does its work by creating a virtual keyboard device in userspace
[04:11] <ogra_> ah
[04:11] <cjwatson> ogra_: yes, it does - g-p-m subscribes to the signal but does nothing with it
[04:11] <cjwatson> hal definitely notices, I just patched it :-)
[04:11] <ogra_> heh, ok
[04:11] <cjwatson> (only in bzr as yet)
[04:11] <enrico> Riddell: it is, and I'd like to get rid of some, but mornfall's not currently active on adept
[04:11] <ogra_> i'll look if there is any kind of patch in a newer gpm
[04:12] <cjwatson> I think gpm-hal-monitor.c is the right place - I'm happy to write the patch if you can review it
[04:12] <cjwatson> since I have all the stuff set up here
[04:12] <ogra_> the one we have is pretty old, i'm still waiting for giskard who wanted to maintain it in debian and ubuntu now ...
[04:12] <enrico> Riddell: tagcolledit built fine with libtagcoll-dev 
[04:12] <ogra_> but i think i'll package the new one myself if he doesnt soon come up with anything
[04:12] <enrico> Riddell: post-etch I'll port it to tagcoll2
[04:13] <Riddell> enrico: ok
[04:14] <ogra_> cjwatson, i'm fine with the patch, but i suspect it makes more sense with a 2.17 package
[04:15] <cjwatson> sure
[04:18] <ogra_> ah, seems device_added is only used in context with bastteries in gpm
[04:18] <ogra_> *batteries
[04:19] <cjwatson> I haven't worked out how it's used at all yet - file/line pointer?
[04:19] <ogra_> gpm-battery.c uses it
[04:19] <cjwatson> ah, is this in 2.17?
[04:19] <ogra_> and gpm-hal.c recieves the event 
[04:19] <ogra_> yep. just got the source
[04:20] <cjwatson> there's no gpm-battery.c in 2.16.1 - gpm-hal.c's implementation of device_added is basically empty
[04:20] <ogra_> oh, ok
[04:20] <ogra_> i didnt compare the two yet ...
[04:21] <cjwatson> I'll grab CVS
[04:21] <ogra_> just grap 2.17.3 from http://ftp.gnome.org/pub/gnome/sources/gnome-power-manager/2.17/
[04:21] <cjwatson> too late
[04:21] <ogra_> thats what will be in the next package
[04:21] <ogra_> ok :)
[04:26] <pitti> Riddell: MIR exiv2 -> it's still in NEW, and the (absent) soname handling of the lib makes me weep
[04:27] <Riddell> pitti: I've not looked at it (I didn't write the MIR) but the Debian packager did say the versioning is unclear
[04:28] <pitti> yes, we probably have to live with that
[04:28] <pitti> I'd just like to take a look at the binaries when they go out of NEW, before that the rdepends won't build anyway
[04:28] <pitti> the rest is okay
[04:29] <Tonio_> pitti: hi
[04:29] <iwj> Keybuk: Do you want me to pick up UdevEvms ?  I have a setup here which would make it quite quick to do I think.
[04:29] <Tonio_> pitti: yeah sorry I wrote the MIR a bit too soon
[04:29] <pitti> Hi Tonio_
[04:29] <iwj> As it's just the same as UdevLvm but for EVMS.
[04:30] <Tonio_> should have wait for the packages to be out of NEW...
[04:30] <Keybuk> iwj: sure
[04:30] <pitti> Tonio_: no problem, I just let it sit there for a while
[04:31] <Tonio_> pitti: okay
[04:32] <pitti> Riddell: firefox-themes-ubuntu, rss-glx, gftp, libgd-graph-perl, oo.o, and quagga will work with graphicsmagick, too?
[04:36] <Riddell> pitti: hmm, good question
[04:47] <ryanakca> I don't know if this is the right place to say this, but on http://packages.ubuntu.com/cgi-bin/download.pl?arch=i386&file=pool%2Fmain%2Fg%2Fglibc%2Flibc6_2.4-1ubuntu12_i386.deb&md5sum=3d7d40e703e91d16e54e64525174d38f&arch=i386&type=main  ,  there are several broken links 
[04:52] <spike> cjwatson: dunno if you ever managed to have a look to that email I sent you about preseeding and serial console, but just wanted to update you that the problem exists on "real" servers too, completely different hw than the one reported in my email
[05:05] <cjwatson> spike: ok, problem is that I have no experience with serial consoles and no hardware here with which to even start trying to reproduce it ...
[05:05] <spike> cjwatson: actually I 'spose I could give edgy a try before anything else
[05:05] <spike> I'll do it on moday and report back
[05:05] <spike> monday*
[05:06] <cjwatson> spike: could you humour me and try adding 'debian-installer/locale=en_US.UTF-8 kbd-chooser/method=us' to your boot parameters?
[05:06] <iwj> dbus--
[05:06] <pitti> hmm, if I fork() in a program, the child looses all global variables?
[05:07] <cjwatson> spike: because even at priority critical, the locale question is going to be asked, and you aren't preseeding it ...
[05:07] <pitti> (and allocated heap variables)
[05:09] <spike> cjwatson: re-read the email I sent: if I remove the serial console it works just fine, which means preseed of itself works
[05:09] <spike> cjwatson: if I plug in a monitor and let it go, without serial console, it works
[05:09] <spike> without any change
[05:10] <spike> besides, I've got d-i debian-installer/locale string en_GB and d-i console-keymaps-at/keymap select uk
[05:10] <spike> in my preseed file
[05:10] <cjwatson> spike: localechooser is sensitive to whether a serial console is attached. please humour me.
[05:10] <spike> oh, good point, will do, thanks
[05:10] <cjwatson> spike: those preseeds won't do anything in your preseed file - the preseed file is read after that point
[05:11] <Keybuk> pitti: in which language?
[05:11] <pitti> Keybuk: C
[05:11] <Keybuk> err?
[05:11] <cjwatson> kbd-chooser/method is recommended over console-keymaps-at/keymap
[05:11] <Keybuk> no...
[05:11] <spike> cjwatson: ok, updating everything and trying,thanks
[05:11] <Keybuk> if you fork in C, and have lost access to the heap or globals, then Mr Pointer has fallen out with Mr Boundaries
[05:11] <pitti> Keybuk: hm, right, I just eliminated the fork(), still doesn't work; nevermind
[05:11] <cjwatson> spike: there's a special different template that's asked in localechooser in the event that you have a serial console
[05:12] <cjwatson> so I suspect that preseeding it properly, as recommended, will work
[05:12] <pitti> Keybuk: in main() I allocate a global char**, and in the child it's suddenly NULL; I suspected the fork() at first, but must be something else
[05:12] <Keybuk> yeah, definitely not the fork
[05:12] <cjwatson> global in what way?
[05:12] <cjwatson> you mean static?
[05:12] <Keybuk> the only difference after a fork is the return value from that function
[05:12] <pitti> cjwatson: yes
[05:12] <cjwatson> file-scoped?
[05:12] <pitti> cjwatson: right
[05:12] <pitti> Keybuk: well, and fds are closed
[05:12] <Keybuk> pitti: no, fds aren't closed
[05:12] <pitti> argh, /me headdesks
[05:13] <cjwatson> fds are closed on exec not fork
[05:13] <Keybuk> cjwatson: and then only if so marked
[05:13] <cjwatson> indeed
[05:14] <pitti> yup, found it; PEBCAK of course
[05:14] <pitti> sorry for the noise
[05:14] <bddebian> cjwatson: Hey, sorry to bug you more but I don't see an attal-themes-medieval source package on packages.u.c or apt-cache madison??
[05:14] <cjwatson> bddebian: correct
[05:15] <cjwatson> what's your point? :-) I said that was a new source, not yet synced
[05:15] <cjwatson> attal-themes-medieval |    0.9.2-1 |      unstable | source, all
[05:15] <Keybuk> pitti: Problem Exists Between Coffee And Konciousness?
[05:15] <cjwatson> it's in Debian
[05:15] <bddebian> cjwatson: We have 10.x in Ubuntu
[05:15] <pitti> Keybuk: Between Cut and Krackful paste, rather...
[05:15] <bddebian> They aren't seperate sources anymore.  The upstream build system changed where you can't build attal without a themes package now
[05:16] <cjwatson> bddebian: new-source can't tell; if it shouldn't be synced, it needs to be blacklisted
[05:16] <pitti> Keybuk: 'char ** foo = ..' doesn't really change the global foo that I added after that...
[05:17] <cjwatson> bddebian: there's no safe way for it to say "the version number of this source package is less than that other version number over there somewhere, therefore I shouldn't sync"
[05:17] <bddebian> cjwatson: Right, sorry.  How should I handle that?  File a bug to ask for it to be blacklisted?
[05:17] <cjwatson> bddebian: ask Keybuk, who has the file open in vim such that I can't just do it now ;-)
[05:17] <Keybuk> heh
[05:17] <Keybuk> Keybuk ALWAYS has the file open
[05:17] <Keybuk> he's a bitch for that
[05:18] <bddebian> hehe
[05:18] <bddebian> Keybuk: Sooo? :)
[05:18] <Keybuk> it's in the other blacklist file
[05:18] <Keybuk> (the one in my head)
[05:18] <bddebian> heh
[05:18] <Keybuk> E: attal-themes-medieval_0.9.2-1.diff.gz (from attal-themes-medieval) is in the DB but isn't an orig.tar.gz.  Help?
[05:18] <Keybuk> ooh
[05:18] <Keybuk> nice error
[05:18] <Keybuk> now I remember why I didn't sync it <g>
[05:18] <Keybuk> you want it blacklisted?
[05:18] <elmo> wtf
[05:18] <bddebian> Keybuk: Yeah, in Edgy we jumped the debian version and the themes package is built from the attal source package now
[05:19] <Keybuk> right
[05:19] <Keybuk> so you want that blacklisted properly?
[05:19] <bddebian> Is it my place to make that decision?
[05:19] <Keybuk> elmo: that's my favouritest EVAH error.  I like it when Soyuz says "Help?"
[05:19] <Keybuk> bddebian: it is now
[05:19] <bddebian> hrm
[05:20] <bddebian> Sure blacklist it and kick the Debian maintainer to wake up and get our version ;-P
[05:20] <cjwatson> Keybuk: is it randomly matching on filenames in the hope that one of them might be a .orig?
[05:20] <elmo> Keybuk: that's my code
[05:20] <elmo> cjwatson: no
[05:20] <elmo> it's specifically asking for an orig.tar.gz
[05:20] <elmo> and soyuz said "here have this diff.gz instead"
[05:20] <elmo> that smacks of some horribleness in the DB
[05:21] <Keybuk> we had that version in dapper
[05:21] <elmo> oh, sorry, no, I'm entirely lieing
[05:21] <Keybuk> as a source package
[05:22] <Keybuk> elmo: err, this source looks utterly bogus <g>
[05:22] <elmo> Keybuk: which source?
[05:23] <cjwatson> ogra_: am I likely to be able to run the gnome-power-manager binary built from CVS without bothering to install it, just with the data from the existing package?
[05:23] <elmo> sync-source or the package we're talking about?
[05:23] <Keybuk> elmo: sync-source
[05:23] <Keybuk> it looks like it'd fail whenever the DB can fess up the source package requested
[05:23] <Keybuk> it's failing because we do have that source in Ubuntu, just published in an older release
[05:23] <cjwatson> mm, yeah, we do
[05:24] <cjwatson> cute
[05:29] <ogra_> cjwatson, well, you will miss some patches, but yes
[05:35] <Keybuk> WHAT IN THE NAME OF THE MOTHER OF ALL THAT IS HOLY AND GOOD IS "iceape" ?!
[05:35] <cjwatson> seamonkey (full mozilla suite) renamed
[05:35] <Keybuk> sheesh
[05:35] <Keybuk> Debian are insane
[05:35] <cjwatson> or maybe just what used to be mozilla-browser. something like that anyway
[05:36] <cjwatson> the ice{ape,dove,weasel} naming scheme is quite cute, I think :)
[05:36] <pitti> cjwatson: did you see the icons? they are even cuter
[05:39] <dholbach> and there's icedax too
[05:39] <Keybuk> what's icedax?
[05:39] <Spads> chatzilla?
[05:39] <dholbach> cdrkit stuff
[05:39] <Keybuk> crazy
[05:40] <dholbach> ROCK :)
[05:40] <Keybuk> ice* muahahaha
[05:40] <pitti> Keybuk: while you are at it, can you blacklist enigmail?
[05:40] <pitti> Keybuk: we have to permanently fork due to that renaming, too
[05:41] <Keybuk> pitti: what did they call that?  iceotter?
[05:41] <pitti> Keybuk: icedove
[05:41] <pitti> (thunderbird)
[05:41] <Keybuk> icedove is thunderbird, isn't it?
[05:41] <Keybuk> right ?
[05:41] <Keybuk> enigmail is its own source
[05:41] <pitti> right, see above
[05:41] <Keybuk> yes ...
[05:41] <pitti> Keybuk: yep, but it produces the tbird enigmail plugin
[05:41] <Keybuk> but they're not renaming that source?
[05:41] <Keybuk> sure, but we can merge that, no?
[05:41] <Keybuk> blacklist = no sync, no mom, etc.
[05:42] <pitti> they even use icedove'ish sdk tarballs in the upstream package, so there's not much to merge
[05:42] <pitti> not blacklisting it doesn't really hurt, it's just a bit confusing
[05:43] <Keybuk> I need to blacklist "mozilla" though
[05:43] <Keybuk> that's a transitional package to iceape now
[05:46] <jdub> banshee deps on boo... interesting
[05:53] <pitti> hey jdub
[05:57] <keescook> mornin' all
[06:16] <pitti> Keybuk: ok, so I got the renaming /etc/udev/rules.d/85-hal.rules -> 95-hal.rules ready; that's confirmed to be the One True Rank now?
[06:19] <Keybuk> pitti: yeah, much better place for it
[06:19] <pitti> ok, then I upload this now
[06:20] <pitti> cjwatson: uploaded your hal patch with that version, in case you want to do Malone juggling for that
[06:23] <cjwatson> pitti: thanks
[06:37] <Riddell> cjwatson: fancy promoting a bunch of things to main for me?
[06:40] <cjwatson> pitti: what's supposed to set HAL_PROP_INPUT_DEVICE?
[06:41] <cjwatson> Riddell: would prefer if Keybuk could do it - I'm beneath a stack of things about six deep at the moment and am terrified of losing context :)
[06:42] <Keybuk> Riddell: which things?
[06:43] <Riddell> Keybuk: libofa, libwibble, libpqxx, xdg-utils
[06:43] <Riddell> all sources and binaries
[06:43] <Riddell> all approved by pitti
[06:44] <cjwatson> Keybuk: has DEVNAME gone away?
[06:45] <cjwatson> hmm, no
[06:45] <Keybuk> cjwatson: hope not! :p
[06:46] <cjwatson> just trying to work out why hald seems to think it's empty here
[06:47] <Keybuk> Riddell: done
[06:47] <cjwatson> 17:37:07.078 [I]  osspec.c:226: SEQNUM=2755, ACTION=add, SUBSYSTEM=input, DEVPATH=/sys/class/input/input54, DEVNAME=, IFINDEX=0
[06:47] <cjwatson> 17:37:07.079 [I]  hotplug.c:171: /sys/class/input/input54 is a class device (subsystem)
[06:47] <cjwatson> (why yes, I am stopping and starting a uinput program rather a lot)
[06:47] <Riddell> thanks Keybuk 
[06:48] <Keybuk> cjwatson: what does udevmonitor -e say?
[06:50] <cjwatson> Keybuk: ... oh, never mind, I've just spotted that the subsequent add of /sys/class/input/input54/event6 came with a DEVNAME
[06:51] <cjwatson> udevmonitor doesn't list DEVNAME for either though
[06:51] <Keybuk> weird
[06:51] <Keybuk> that implies there was no device for it?
[06:51] <cjwatson> ah, no, it does later on
[06:51] <Keybuk> [UEVENT]  is what came from the kernel
[06:51] <cjwatson> that devpath seems to get added, then removed, then added again
[06:51] <Keybuk> [UDEV]  is what udev thought about it
[06:51] <cjwatson> oh, ok, I just suck then
[06:52] <cjwatson> I've been deep in the twisty udev/dbus/hal/g-p-m stack for hours
[06:58] <cjwatson> damnit, why does gpm_hal_device_has_capability not work
[07:18] <seb128> could anybody give a retry to gedit build on amd64?
[07:19] <elmo> Burgwork: ping
[07:19] <Burgwork> elmo: pong
[07:19] <Burgwork> geez, everybody is looking for me
[07:20] <iwj> Keybuk: udev-evms done too.  Let me know if I can be of any more assistance.
[07:21] <Keybuk> iwj: want to go at udev-devmapper? :)
[07:21] <Keybuk> complete the trilogy
[07:21] <Keybuk> udev-device-mapper ?
[07:22] <LaserJock> Burgwork: you're a wanted man ;-)
[07:22] <iwj> Keybuk: Sure.  Very much the other end of the spectrum.  I'll take a look at that on Monday.
[07:23] <iwj> It's good that I've had an excuse to play with udev, which I previously didn't understand at all.
[07:23] <Keybuk> it's not too difficult really; it's basically just a rule processor for events from the kernel
[07:23] <Keybuk> the trick is mostly understanding the kinds and content of events for each device
[07:23] <Keybuk> would be good to have someone else on the team who can grok it
[07:24] <iwj> mvo: http://www.chiark.greenend.org.uk/~ian/bzr/apt-breaks-iwj/ has that dist-upgrade Breaks: fix.
[07:24] <iwj> mvo: But I still need to talk to you about the dist-upgrader.
[07:24] <iwj> Keybuk: It's a crazy crazy programming language.
[07:25] <dholbach> iwj: mvo is not here
[07:25] <iwj> dholbach: Oh, is he on holiday already ?
[07:25] <Keybuk> iwj: it didn't start out as one
[07:25] <dholbach> no, he was travelling and should be around a bit later
[07:25] <Burgwork> elmo: pm me if needed
[07:25] <Keybuk> but has had turingness bolted on
[07:25] <iwj> dholbach: Ah.  There's no urgency; it can wait until next week.  The apt thing is something mvo asked for.
[07:26] <dholbach> alrighty
[07:26] <iwj> Keybuk: Always happens.  It's usually best to design it in.
[07:26] <Keybuk> iwj: if I didn't know better, I'd say there was a planet-sized hint going on there :p
[07:26] <iwj> I don't do hints :-).
[07:27] <iwj> But now that you come to mention it ...
[07:27] <iwj> *grin*
[07:28] <iwj> Keybuk: Is that `watershed' feature going to make it into the archive soon ?  I haven't really tested the raceyness or otherwise of the evms change because it depends on watershed to avoid the race.
[07:29] <Keybuk> iwj: yeah, the patch is sitting in my inbox, I just haven't got around to testing it yet
[07:29] <iwj> Keybuk: If you mail me a copy when you have a mo I'd be happy to look at it.  It's the kind of thing that can be subtly wrong.
[07:29] <iwj> So another brain thinking about it would probably be worthwhile.
[07:30] <Keybuk> I've got a small stack of udev changes that need doing, I should probably tackle them soon next week
[07:30] <iwj> Right.
[07:30] <Keybuk> need to see how this modprobe patch works as well
[07:30] <iwj> modprobe patch ?
[07:30] <Keybuk> it builds modprobe into udev
[07:30] <iwj> Yikes.
[07:30] <Keybuk> so you don't need to parse modules.alias, modules.dep and /etc/modprobe.conf every time a device gets inserted
[07:31] <iwj> That would be a win, I suppose.
[07:32] <Keybuk> also means we can do fast lookups of modalias strings into driver names (when we get that kernel patch)
[07:32] <Keybuk> so can make device/driver binding decisions in udev
[07:44] <mvo> hey iwj - you wanted to discuss something?
[08:31] <jdong> keescook: another universe security thing.... flexbackup
[08:31] <jdong> keescook: in dapper/edgy, temporary file creation insecurity
[08:32] <keescook> jdong: yeah, I think I saw the CVE go by for that.
[09:08] <siretart> did anyone already request to get ubuntu-devel-discussed added at gmane?
[11:05] <sfllaw> kylem: What do you know about ACPI, Power Buttons, and Laptops?
[11:06] <kylem> not a terrible amount, mjg59 would be your best bet...
[11:08] <sfllaw> mjg59: What do you know about ACPI, Power Buttons, and Laptops?
[11:08] <Burgwork> sfllaw: what he doesn't know is a better question
[11:11] <Adri2000> builds in "dependency wait" are automatically re-ran as soon as the dependency is available?
[11:12] <sfllaw> mjg59: https://bugs.launchpad.net/distros/ubuntu/+source/gnome-power-manager/+bug/68760
[11:12] <Ubugtu> Malone bug 68760 in gnome-power-manager "no power button in edgy" [Undecided,Needs info]  
[11:12] <sfllaw> mjg59: Basically, the system is not responding to the PWRF.
[11:12] <sfllaw> mjg59: I'm wondering if it's using the PWRB instead?
[11:12] <sfllaw> mjg59: My machine also exhibits similar behaviour, although it's a Thinkpad T60p.
[11:16] <giskard> sfllaw, i guess it's an acpi problem
[11:18] <sfllaw> giskard: It looks like some problem with Linux-ACPI and not userland ACPI.
[11:18] <LaserJock> when is dash used and when is bash used? I don't quite understand
[11:18] <giskard> bash is used as shell, dash is used for the pre/post script, afaik.
[11:19] <giskard> sfllaw, if linux-acpi means kernel side, yes.
[11:19] <LaserJock> well, but on a user's system
[11:19] <LaserJock> I'm getting bug reports about breakage in apps, supposedly from bash->dash
[11:19] <_ion> dash is used for scripts, bash is used as the interactive shell.
[11:20] <sfllaw> LaserJock: /bin/sh is dash now.
[11:20] <LaserJock> I know
[11:20] <_ion> Such scripts should be fixed, either by modifying them to POSIX syntax or changing #!/bin/sh to #!/bin/bash
[11:20] <LaserJock> but the user's shell is still bash, right?
[11:21] <mc44> yep
[11:22] <LaserJock> hmm, do we  have any automated way to know when something has broken because of bash->dash ?
[11:23] <giskard> all script run with  set -e
[11:25] <cjwatson> LaserJock: checkbashisms (in devscripts) is a pretty good start
[11:26] <Fujitsu> cjwatson: Can you please finish off #43150 if/when you have the time?
[11:26] <cjwatson> still way too much polling in there, but it's probably a kernel problem ...
[11:26] <LaserJock> cjwatson: ah, thanks for the tip. texmacs seems to have several plugins with bashims
[11:29] <cjwatson> Fujitsu: looking
[11:31] <Fujitsu> Thanks.
[11:32] <cjwatson> Riddell: thanks for your ubiquity patch yesterday, but unfortunately it still doesn't seem to show the nested list of radio buttons under "Guided - use entire disk"
[11:33] <cjwatson> Riddell: it's supposed to look like this:
[11:33] <cjwatson> * Guided - use entire disk
[11:33] <cjwatson>   * <description of first disk>
[11:33] <cjwatson>   * <description of second disk>
[11:33] <cjwatson>   * ...
[11:33] <cjwatson> * Manual
[11:33] <cjwatson> at the moment I just get the outermost list
[11:37] <_ion> Now that ubuntu-devel@ is moderated, i wonder how frequently/actively the moderation queue is checked?
[11:38] <LaserJock> _ion: heh, I thought it was > /dev/null
[11:39] <cjwatson> Fujitsu: I believe I have to wait for gcl to build everywhere before accepting maxima. Please https://launchpad.net/distros/ubuntu/+source/gcl/+subscribe yourself in the meantime, as MOTU/SRU says
[11:40] <Fujitsu> cjwatson: That is correct, and that I shall do.
[11:41] <Fujitsu> I've subscribed to both.
[11:41] <cjwatson> I saw you were already in a team subscribed to maxima.
[11:41] <Fujitsu> That is correct.
[11:42] <Fujitsu> Thanks for finishing this off.
[11:42] <cjwatson> sorry for the delay
[11:58] <bluefoxicy> Alright
[11:58] <bluefoxicy> I'm gonna go out on a limb and try to get qvm86 to work, and get Edgy or Dapper to boot under it
[11:58] <bluefoxicy> I'm thinking two things:
[11:59] <bluefoxicy> A) Someone buy KQemu so that @%*@( gives us the source code
[11:59] <bluefoxicy> B) Get qvm86 running Ubuntu
[11:59] <bluefoxicy> (B) will be cheaper, me thinks.  Either way, I want something that I can throw onto the LiveCD that when popped into a Linux/Windows host will go, "Oh, you want to run the LiveCD in a virtualized environment?" and do so at full speed.
[12:00] <shackan_> you want to ship qemu with the livecd?
[12:00] <bluefoxicy> (there's also option (C), I start probing KQemu myself and reverse-engineer it)
[12:01] <bluefoxicy> shackan_:  it's been a flighting fantasy of some liveCD makers to have the liveCD run without booting off it; in fact, IIRC a specific version of Knoppix loads Qemu when it's stuck into a Windows machine
[12:01] <bluefoxicy> but it's slow as ass.
[12:01] <shackan_> doesn't seem something worth spending one's time on, especially when you could improve qvm86 instead
[12:02] <bluefoxicy> qvm86 is a GPL'd RE of kqemu, which is support framework for qemu
[12:02] <shackan_> I know
[12:02] <shackan_> vmplayer is too slow too ?
[12:02] <bluefoxicy> vmplayer is not BSD/GPL/LGPL
[12:03] <bluefoxicy> I highly doubt they're going to stick that on the LiveCD
[12:03] <shackan_> ok, and neither is kqemu
[12:03] <bluefoxicy> qvm86 is
[12:03] <shackan_> but what's so wrong about kqemu ? it can't be distributed or something ?
[12:04] <bluefoxicy> kqemu can be, but it'll take money, which can be avoided
[12:04] <bluefoxicy> yes
[12:04] <bluefoxicy> hold on a sec
[12:04] <bluefoxicy> http://qemu.org/qemu-accel.html
[12:04] <bluefoxicy> The QEMU Accelerator is free to use, but it is a closed source proprietary product. You are not allowed to distribute it yourself to other people without an explicit authorisation. Distributors wishing to include the QEMU accelerator on CDs, ISO images or packages must contact the author to know the exact terms.
[12:05] <bluefoxicy> shackan_:  he is tightly controlling it because he wants a wealthy venture capitalist to rain money down on him
[12:05] <shackan_> bluefoxicy, there's nothing wrong with willing to make money from your work :)
[12:06] <bluefoxicy> if someone wants to buy it off him that's great; but there's no market for it and nobody's paid him anything yet, and i'm not rich, so I need another route
[12:07] <shackan_> so qvm seems the only way, if you have the skill and a lot of time to invest
[12:07] <bluefoxicy> shackan_: http://thread.gmane.org/gmane.comp.emulators.qemu.qvm86/19/focus=19 btw updates qvm86 to be closer to kqemu 1.3
[12:08] <shackan_> (I still don't buy the idea of emulating live cds)
[12:09] <bluefoxicy> why not
[12:09] <shackan_> because I don't see the issue in rebooting for a sec
[12:10] <bluefoxicy> having to close all open programs?
[12:10] <bluefoxicy> I would hate to reboot right now
[12:10] <bluefoxicy> my IRC buffers are full etc etc
[12:10] <bluefoxicy> I have dozens of firefox tabs open and such
[12:11] <bluefoxicy> And I know a lot of people who think LiveCDs will trash your hard disk
[12:11] <bluefoxicy> especially college teachers that have a heart attack when i throw one into a machine
[12:11] <shackan_> which is stupid
[12:11] <bluefoxicy> I know.