[12:33] <sistpoty> Kamion | mdz: what's the current procedure to get an universe package into dapper-updates?
[12:33] <mdz> sistpoty: it's being written, due out tomorrow
[12:34] <mdz> will be on -devel-announce when it's done
[12:34] <sistpoty> mdz: ok, thanks
[12:40] <ogra> hmm, no knot3 ?
[12:43] <tseng> ogra: i can upload right?
[12:43] <tseng> ogra: and it will just be held
[12:44] <ogra> right
[12:44] <tseng> ok
[01:57] <zul> mdz: ping
[01:58] <mdz> zul: pong
[01:58] <mdz> I was just trying out your Xen howto
[01:58] <zul> and?
[01:58] <zul> still needs some work i think
[02:06] <mdz> and I've made some edits you may want to review
[02:07] <zul> sure no problems...the kernels in the /boot directory are named that way because of kernel-package
[02:08] <mdz> zul: is there a generic Xen howto you can link to which picks up where yours leaves off?
[02:09] <zul> yes debian-administration site
[02:09] <zul> http://www.debian-administration.org/articles/396
[02:10] <zul> as well im working on the restricted modues, meta-xen, and a domU kernel as well
[02:10] <mdz> zul: that would be a good link to add to the end of your wiki page
[02:11] <zul> ok
[02:12] <zul> mdz: there is a git repository as well hosted by olpc i could send you the url if you wish
[02:13] <bddebian> Howdy folks
[02:13] <zul> as well Mithrandir has been contributing some patches 
[02:15] <zul> http://dev.laptop.org/git.do?p=projects/ubuntu-xen;a=summary fyi
[02:16] <BenC> zul: I contributed a "what the hell were you thinking taking on xen packaging" a few times, don't I get some credit? :)
[02:16] <zul> BenC: yeah you did, and now i lost hair because of it :)
[02:17] <LaserJock> heh, I wonder how BenC can keep all that hair sometimes
[02:17] <BenC> I hear working on archive maint is cake work, so do that for awhile ;)
[02:18] <zul> no thats ok, im crazy enough
[02:31] <BenC> Kamion: ping
[02:49] <terlmann> i have a major ubuntu ptoblem! i tried to run msudo nautilus as user terlmann but the thing ran as "hal" and now my screen is whacked out,the bottom menu are 3 inches from the bottom of the screen,and the mouse pointer has to locate 1 inch BELOW the dialog i wanna click... has anyone got a solution?
[02:49] <terlmann> HELP !!
[02:49] <jdong> terlmann: this is not a support forum; this channel is for developers of ubuntu. Please try #ubuntu or another support method instead
[02:50] <terlmann> but i need developer strength formula,real programmer support!
 Bluefox: the poor asian language support in linux is bad :\
[03:21] <bluefoxicy> o.O
[03:21] <bluefoxicy> he's using knot2 now
[03:21] <bluefoxicy> I thought there was good hongkongese support
[03:21] <slomo_> doko: ecj-bootstrap-gcj doesn't want to run postinst in the buildd chroots :/ http://librarian.launchpad.net/4209912/buildlog_ubuntu-edgy-i386.ikvm_0.26.0.1-2ubuntu2_FAILEDTOBUILD.txt.gz
[03:21] <bluefoxicy> doko:  you around?
[03:41] <Frederick> folks why doesnt ubuntu features the dgb info for image magick?
[03:42] <bddebian> Frederick: As I told you earlier today, all Ubuntu and Debian packages strip their binaries to conserve space on the archives :-)
[03:43] <bluefoxicy> aww man, sourceforge is up but the project web server is down, what the ass
[03:46] <sistpoty> bluefoxicy: if you want to get to a download page, you can do so with sourceforge.net/projects/<project>
[03:46] <bluefoxicy> sistpoty:  I want to finish my web page before the deadline.
[03:46] <bluefoxicy> I don't want to have to adjust the time on my project
[03:46] <sistpoty> he, well can't help you there then ;)
[03:50] <bluefoxicy> sistpoty:  can you help me by somehow getting OLPC to give me an OLPC?  ;)
[03:50] <bluefoxicy> (they're not for sale normally-- though I think they're not yet finished)
[03:51] <sistpoty> bluefoxicy: magic is beyond my abilities ;)
[03:51] <bluefoxicy> heh.  I wish i had money when they were running the pledge
[03:51] <bluefoxicy> they were selling them, you could plegde $300 for a unit, and the other $200 bought 2 more for poor people
[03:52] <bluefoxicy> which is a good deal
[03:53] <bluefoxicy> there's an Ubuntu OLPC spec somewhere too, which I'd like to be able to test out; plus it'd be a cheap and easy to carry around internet/IRC connection, since it's got full wifi :D (hey I can't be all charity)
[03:54] <neuralis> bluefoxicy: we were certainly *not* selling them.
[03:54] <bluefoxicy> neuralis:  lemme see if I can dig it up.
[03:55] <neuralis> bluefoxicy: the pledging was an unofficial pledgebank petition.
[03:55] <jdub> neuralis: oh, ivan - never made the connection between you and your nick :)
[03:55] <bluefoxicy> neuralis:  AH!  I didn't know it was unofficial, damn slashdot.
[03:55] <Frederick> bddebian, but then I cant debug my files and there should be a package wich holds debug info =/
[03:56] <bddebian> Frederick: Sure you can, you just need to build unstripped packages :-)
[03:56] <bluefoxicy> neuralis:  I've actually considered the prospect of enhancing primary education in developed countries with the same technologies; we're certainly not going to hand out $1200 laptops to American children for first grade math
[03:56] <neuralis> jdub: no worries, it just means my nick joins the ranks of kam ion, key buk, infi nity, mith randir, etc. spaces inserted to protect the innocent from their irc client beeping ;)
[03:56] <bluefoxicy> But it looks like that angle isn't going to be aimed at either.
[03:57] <Frederick> bddebian, apt is suspended =/
[03:57] <neuralis> bluefoxicy: it is. we're not at all restricted to the third world, nor were we ever supposed to be. we're just starting there.
[03:57] <bddebian> Frederick: Still?
[03:57] <jdub> neuralis: ha ha ha
[03:58] <Frederick> yep
[03:58] <Frederick> why don't they simply block the package?
[03:58] <bluefoxicy> neuralis:  ah cool.  Any plans to up the ante in the first world?
[04:00] <neuralis> bluefoxicy: google 'romney olpc'
[04:00] <sistpoty> bddebian: no linda issue on gaim-libnotify for me... :/
[04:00] <sistpoty> oops wrong channel
[04:01] <bddebian> sistpoty: Yeah, don't talk to me in here.. ;-P
[04:01] <sistpoty> hehe
[04:02] <bluefoxicy> $150-$300 per unit in the first world would supply a sizeable profit.. 37.9 million primary schoolers... divide by 5... about 7 million.. $350 million profits at $150 ... America would fetch enough to pay for 3,500000 units in the third world, per year
[04:02] <bluefoxicy> (I am an EVIL economist)
[04:02] <bluefoxicy> neuralis:  will do
[04:03] <YokoZar> Is it a good idea to put lone virtual packages in the build depends, eg libcupsys-dev?
[04:03] <bluefoxicy> Mitt Romney?
[04:04] <sistpoty> YokoZar: unless lp can cope with it now: no, you should resolve it to a real package
[04:04] <YokoZar> lp?
[04:05] <sistpoty> YokoZar: launchpad (soyuz to be more specific)
[04:05] <YokoZar> I was more worried about apt-get build-dep myself
[04:07] <sistpoty> no idea about that really... but if you're talking about a package in the archive, it first needs to get through soyuz ;)
[04:35] <infinity> YokoZar: You should always specify a preferred alternate.
[04:35] <Burgundavia> mdz: do you mind if I mention https://wiki.ubuntu.com/Bug57153IncidentReport in UWN 14 (due out on Sat.)
[04:36] <Burgundavia> mdz: if you want me to leave it out until next week, I will
[04:36] <infinity> YokoZar: So, "Build-Depends: libcupsys2-dev | libcupsys-dev"
[04:36] <YokoZar> infinity: yeah, thanks
[04:36] <Frederick> is apt still blocked?
[04:44] <sistpoty> quick question: should the libtool information (*.la) be shipped in a -dev package?
[04:45] <sistpoty> (for reference: comments on http://revu.tauware.de/details.py?upid=3126)
[04:52] <bddebian> sistpoty: Guess they are all asleep? :-)
[04:53] <sistpoty> or busy ;)
[04:53] <sistpoty> but I think your assumption is more likely 
[04:54] <bddebian> Never count on anything from my dumb ass :-)
[04:55] <sistpoty> :P
[05:10] <SEJeff> I'm going to guess that the earlier incident prevented knot 3 from being released
[05:11] <Frederick> SEJeff is apt back?
[05:11] <LaserJock> there was an incident?
[05:12] <SEJeff> https://wiki.ubuntu.com/Bug57153IncidentReport
[05:12] <imbrandon> afaik that was august
[05:12] <imbrandon> 21 22
[05:13] <imbrandon> nothing much to do with knot 3
[05:13] <SEJeff> imbrandon: Read the completion date
[05:13] <SEJeff> Completion date: Friday, 15 September 2006
[05:13] <LaserJock> I don't see the correlation, but ...
[05:13] <LaserJock> I don't think it has anything to do with knot 3, but I could be utterly wrong :-)
[05:13] <imbrandon> i still dont see how that has to do with knot 3 , and afaik its not delayed just not released
[05:14] <SEJeff> BenC was working all morning on a new l-r-m and bumped up the kernel abi
[05:14] <imbrandon> btw moins LaserJock ;)
[05:14] <SEJeff> that was the fix that bug
[05:14] <LaserJock> imbrandon: hola
[05:15] <imbrandon> SEJeff, well i dont think that had alot to do with it either but i could be wrong, best case if your dieing to know is wait a few hours ( morning EU time ) and ask
[05:15] <imbrandon> just my 0.2c
[05:16] <SEJeff> imbrandon: I've got specto watching http://cdimage.ubuntu.com/releases/edgy/, it will tell me when. Thanks
[05:45] <fabbione> morning guys
[05:49] <Burgundavia> morning fabbione
[05:54] <bddebian> Hello fabbione, Burgundavia
[05:54] <jsgotangco> hello
[05:55] <bddebian> Hi again jsgotangco :-)
[06:03] <desrt> ajmitch; ping
[06:09] <lynn> hi - a quick question - during the install I filled in the blanks and after the reboot my user and pass aren't recognized........is the default for these?..........I installed ubuntu alternative 
[06:12] <imbrandon> it should be what it asked you durring the install
[06:12] <imbrandon> there is no way to recover or reset it that i know of
[06:12] <imbrandon> check you caps lock etc
[06:12] <imbrandon> and for future ref try #ubuntu this is the dev channel ;)
[06:20] <lynn> tried all that .............:(
[06:22] <ajmitch> desrt: yes?
[06:22] <desrt> ajmitch; can you upload your updated libcm?
[06:22] <ajmitch> sure, I'll dig it out sometime tonight
[06:23] <desrt> ajmitch; update spiftacity too while you're at it, since it'll be able to build again with the new libcm :)
[06:23] <desrt> you'll make a lot of people happy
[06:23] <ajmitch> yeah, I was doing that at one point
[06:24] <ajmitch> breaking metacity to produce a spiftacity package is a little more work, I had it done for 2.15.x
[06:24] <ajmitch> & then dholbach & seb kept on updating metacity on me :)
[06:26] <ajmitch> excellent, local conflicts in libcm checkout
[06:37] <Burgundavia> mdz: https://wiki.ubuntu.com/EdgyEft/Knot3 any thoughts?
[06:43] <desrt> Burgundavia; needs more beavers
[06:44] <Burgundavia> desrt: umm.... ???
[06:46] <desrt> Burgundavia; the arabic screenshot looks bad as it is
[06:46] <desrt> Burgundavia; i'd either get rid of it or move it to the front
[06:46] <desrt> Burgundavia; i don't realise that arabic is RTL and i look at the menubars of oo.o and gimp and say "oh.  blank spaces.  maybe they haven't finished the translating yet."
[06:47] <desrt> Burgundavia; if it was on top you could see the text
[06:47] <Fujitsu> desrt, that's what I initially thought.
[06:47] <Fujitsu> Then I realised it was probably RTL.
[06:47] <desrt> Burgundavia; also.  gimp is active in the russian screenshot but none of the others
[06:47] <Burgundavia> oh, right
[06:47] <Fujitsu> desrt, true.
[06:48] <Fujitsu> Also: This screenshot shows this new feature/
[06:48] <Burgundavia> given my gimp-foo sucks
[06:48] <desrt> also - fix your links.. i wanna read about upstart :)
[06:50] <Burgundavia> right
[06:50] <desrt> also -- if knot3 is gonna release soon you should probably make sure a new openoffice upload has been completed :)
[06:50] <desrt> but that's not really your job
[06:50] <Burgundavia> no, it is not, thankfully
[06:50] <desrt> well, bug someone :)
[06:51] <Burgundavia> doko: ping
[06:51] <Burgundavia> desrt: I just did
[06:51] <desrt> 100% of the time crash-on-save in the office suite is a pretty big eyesore in a prerelease :)
[06:54] <Burgundavia> desrt: actually, it is only crash when save-as, not save
[06:55] <desrt> Burgundavia; well.. save new document -> save as
[06:55] <Burgundavia> yes, like I said, any sort of save as
[06:55] <Burgundavia> purely saving an existing document works
[06:55] <desrt> i suspect it's actually any time the file chooser shows
[06:55] <desrt> so it might happen on open too
[06:56] <Burgundavia> OO.o so needs to die
[06:56] <desrt> it's a shame that abiword sucks
[06:56] <desrt> because i really really like abiword
[06:56] <Burgundavia> so does FF, Gaim and GIMP
[06:56] <infinity> Kamion: I suspect the update-alternatives breakage in usplash is because the .so shipped by usplash is no longer a registered alternative.  That seems to be a mistake.
[06:56] <desrt> ooo -> abi
[06:56] <desrt> ff -> ephy
[06:56] <desrt> gaim -> gossip
[06:56] <desrt> gimp -> ?!?!?
[06:56] <infinity> Kamion: Oh, cause it doesn't ship one anymore...
[06:56] <Burgundavia> fspot
[06:56] <desrt> i'm afraid we'll have to disagree :)
[06:56] <Burgundavia> desrt: you are right
[06:57] <Burgundavia> the open dialog causes it crash as well
[06:57] <infinity> Kamion: Doubly a mistake, I guess.
[06:57] <infinity> Seveas: ?
[06:57] <desrt> ok.  it is time for bed.
[06:57] <desrt> Burgundavia; congrats on the so-far-so-good release notes.  have fun finishing them up.
[06:57] <desrt> cheers.
[06:58] <Burgundavia> I don't know why Mozilla doesn't consider Ephy to be the Camino of Linux
[06:59] <infinity> Because it's crap?
[06:59] <Fujitsu> +1 infinity.
[07:01] <Burgundavia> infinity: Mozilla is crap as a platform? Mozilla is crap as a product? yes, I would agree
[07:01] <infinity> No, epiphany is crap as a browser. :)
[07:01] <Burgundavia> now there we have to disagree
[07:01] <infinity> I use it daily along with firefox, and it irritates the piss out of me.
[07:02] <Burgundavia> FF does that for me
[07:02] <infinity> Makes sense. :)
[07:03] <Burgundavia> well your sanity has clearly boiled away in the sun down under
[07:03] <Fujitsu> Uh... Silly North Americans, with little/no sanity :P
[07:04] <Burgundavia> Fujitsu: Pot, kettle...
[07:04] <Fujitsu> Burgundavia: ?
[07:04] <Burgundavia> anybody else notice how the new battery notifications cover up your desktop switcher?
[07:05] <Burgundavia> Fujitsu: the pot calling the kettle black
[07:05] <Fujitsu> Burgundavia, yes, I noticed that well over a month ago :P
[07:05] <Fujitsu> Burgundavia, probably.
[07:12] <Burgundavia> hmm, no Keybuk
[08:12] <buzzen> update-grub now converts kopt=root=/dev/md0 into kopt=root=UUID=(uuid of filesystem). this does not seem to work on my raid device. how can I disable this ?
[08:13] <buzzen> feels like a bug to me
[08:13] <buzzen> (or untested with raid)
[08:14] <fabbione> buzzen: known and fixed bug
[08:14] <fabbione> the new mdadm that handles that is waiting knot-3 CD to be out to be unleashed in the archive
[08:14] <fabbione> a fix exists and it's there..
[08:14] <buzzen> ok thanks
[08:15] <fabbione> buzzen: i assume that it won't be long (max 24 hours) before it will be there
[08:15] <buzzen> if I remove the evms package, does it also disable all evms activation (also in initrd for example)
[08:15] <buzzen> ?
[08:15] <madduck> buzzen: yes
[08:16] <fabbione> madduck: the problem is udev/md interaction. md doesn't kick udev hard enough to create /dev/disks/by-uuid/symlinks...
[08:16] <fabbione> madduck: so the fixed package does just that
[08:16] <buzzen> ok thanks.. ive had enough of evms... it also seems to take over mdadm configured arrays without permission at times
[08:16] <fabbione> that's why UUID is not there with the old one
[08:16] <madduck> fabbione: 2.5 works, btw.
[08:16] <fabbione> 2.5 what?
[08:16] <madduck> mdadm :)
[08:17] <fabbione> well i could ask for a UVF exception...
[08:17] <madduck> you don't want to do that at this stage, i think.
[08:17] <buzzen> so new mdadm will also be in edgy soon 2.4.1 is rather old
[08:17] <buzzen> ?
[08:17] <madduck> too many changes between 2.4.1-6 and 2.5.3.gitXXX-4
[08:18] <buzzen> 2.6.17 kernel + mdadm is more powerful than evms in some ways now.
[08:18] <buzzen> with online reshaping..
[08:18] <buzzen> i noticed that is disabled in ubuntu kernels..
[08:20] <Mithrandir> sladen: that xorg space bar bug of yours is impressive.
[08:21] <fabbione> buzzen: we are too close to release to import new versions from upstream. This one is known to work just fine.
[08:22] <buzzen> referring to the 2.5.3 version? any 2.5.x is good enough
[08:22] <buzzen> so thats ok
[08:26] <buzzen> one thing thats bugging me. either im doing something wrong or. I created another raid device. and after a reboot, the new device (i called /dev/md1) has become /dev/md0 and my old one md1
[08:26] <buzzen> i thought using a mdadm.conf locked it down
[08:27] <buzzen> is the mdadm.conf being used by update-initramfs ?
[08:32] <fabbione> buzzen: no that's related only to the order in which devices are discovered. there is no locking in that regard. 
[08:32] <fabbione> it's a FIFO
[08:32] <fabbione> the first raid that's discovered becomes md0
[08:32] <fabbione> and so on
[08:32] <buzzen> oh.
[08:32] <fabbione> if your second raid is discovered first, it will be md0
[08:33] <buzzen> I dont like the order though :-)
[08:33] <jdub> fabbione: is the initramfs/uuid/md stuff sorted now?
[08:33] <fabbione> jdub: i have the package in the unaccepted due to knot-3
[08:33] <fabbione> but the fix is there and ready to be unleashed
[08:33] <jdub> fabbione: rock!
[08:33] <jdub> fabbione: i'll reboot my server as soon as the update goes thru :-)
[08:34] <buzzen> fabbione: I guess I will have to live with it :-) So I shouldnt refer to them as /dev/md0 but using the UUID in the fstab for example ?
[08:34] <fabbione> jdub: i did test it yesterday before publishing the fix
[08:34] <fabbione> buzzen: that would be the best once the fix is in the archive yes..
[08:34] <buzzen> fabbione: incase a change in teh kernel alters the order etc.
[08:34] <fabbione> exactly
[08:34] <fabbione> more than in the kernel, i would say in your device chain
[08:34] <fabbione> but you get the idea
[08:35] <buzzen> would be handy to lock them down by uuid though.like you can with network devices and mac addresses
[08:35] <fabbione> i need to go offline for 20 minutes 
[08:35] <fabbione> later
[08:35] <fabbione> you can
[08:35] <buzzen> how ?
[08:35] <fabbione> it needs the fix that's waiting in the archive
[08:35] <buzzen> aah ok :)
[08:35] <fabbione> mount by UUID
[08:35] <fabbione> that's the same thing that break root on raid at the moment
[08:35] <fabbione> i really need to take off for 20
[08:35] <fabbione> later
[08:35] <buzzen> cheers.
[08:47] <madduck> fabbione: i am curious as to why thoe problems exist on Ubuntu. do you deal with RAID on configurations that change?
[08:48] <madduck> because otherwise, the order in which RAID arrays are assembled/detected is deterministic
[08:53] <fabbione> madduck: no the order is not deterministic. 
[08:53] <fabbione> the bug people are talking about is the mount of raid via UUID when it's mounted as /
[08:54] <buzzen> fabbione: i remember reading about md driver getting support for saving raid resync progress so it can continue after a reboot. Don't suppose you know when this was added to the kernel ?
[08:54] <fabbione> buzzen: i know it's there.. when it was introduced.. no idea
[08:55] <fabbione> probably sometimes after .12
[08:55] <buzzen> do you know if it works for old 0.90 superblocks or just the new formnat ?
[08:56] <buzzen> i nice big changelog for the md driver would be nice. guess that doesnt exist in one place..
[08:56] <fabbione> the format of the sb didn't change
[08:56] <madduck> fabbione: hm. right, ubuntu uses mdrun, which makes it non-deterministic
[08:57] <buzzen> fabbione: you have 0.90 sb and 1.0 sb which is more flexible/newer
[08:57] <buzzen> it has less restrictions..
[08:58] <buzzen> (supports more disks and more space for "expansion" etc)
[09:00] <buzzen> but im not sure if there is "space" in the 0.90sb to sotre this resync "progress". certainly it doesnt seem to be on my system.. i didn't try with 1.0sb
[09:01] <fabbione> buzzen: according to git the first patch to support partial resync did hit kernel last year in June
[09:02] <fabbione> and still according to other git entries, the sb format is updated by the running kernel when possible
[09:02] <fabbione> and when required
[09:02] <fabbione> so basically an old version-0.90 is upgraded to 0.91 or 1 when needed
[09:03] <buzzen> ive not heard that before. but some of the superblocks are stored in different places ?
[09:03] <buzzen> how could it handle that..
[09:03] <pitti> Good morning
[09:04] <Burgundavia> Mithrandir: ping
[09:04] <Burgundavia> pitti: morning
[09:04] <fabbione> buzzen: i am only reading git commit logs
[09:04] <fabbione> buzzen: not the code
[09:05] <buzzen> fabbione: yup. thanks :)
[09:05] <fabbione> and reading an old sb and write to the new format is not rocket-science...
[09:05] <buzzen> fabbione: the kernel md driver and mdadm is not documented as well as it could be..
[09:05] <buzzen> fabbione: i wondered perhaps if there was data on that portion of the disk for example. but ok.. i dont know the details really
[09:05] <fabbione> buzzen: patches are welcome
[09:06] <pitti> hey Burgundavia 
[09:06] <fabbione> no, there is no data after the sb
[09:06] <fabbione> the sb is located at the end of the device
[09:06] <fabbione> and it allocates a big chunk of disk to store data
[09:06] <buzzen> fabbione: sb 1.1 is located at the beginning.
[09:06] <buzzen> or 1.2 i forget
[09:06] <fabbione> and there is space for extensions
[09:07] <buzzen> either  at  the end (for 1.0), at the start (for 1.1) or 4K from the start (for
[09:07] <buzzen>                      1.2).
[09:07] <fabbione> buzzen: nope.. the md superblock has always been in the same place since god created light
[09:07] <buzzen> fabbione: then mdadm man is lying ?
[09:07] <fabbione>  * If x is the real device size in bytes, we return an apparent size of:
[09:07] <fabbione>  *
[09:07] <fabbione>  *      y = (x & ~(MD_RESERVED_BYTES - 1)) - MD_RESERVED_BYTES
[09:07] <fabbione>  *
[09:07] <fabbione>  * and place the 4kB superblock at offset y.
[09:07] <fabbione>  */
[09:07] <fabbione> this is kernel code
[09:08] <buzzen> see. you cant even trust the documentation then! :D
[09:08] <fabbione> patches are welcome
[09:08] <buzzen> :)
[09:08] <buzzen> ill put thgat on my todo list
[09:10] <Mithrandir> Burgundavia: hi
[09:10] <Burgundavia> Mithrandir: http://www.ubuntu.com/testing/knot3 is up, but should I leave the "not yet released" on the page?
[09:11] <Burgundavia> issue is, I am about to go to sleep and so you would need to find somebody else to edit it if you release Knot 3 in the next 8 hours
[09:11] <Mithrandir> Burgundavia: yes, please leave the not yet released.
[09:11] <Burgundavia> ok, will do
[09:11] <Mithrandir> thanks
[09:12] <Burgundavia> you will need to find Matthew Nuzum or Heno to get it removed at the right time
[09:12] <Mithrandir> Burgundavia: yeah, shouldn't be a problem.
[09:18] <pitti> hey seb128
[09:18] <seb128> hi pitti
[09:21] <seb128> how is knot-3 going? Current iso are good to play with?
[09:36] <Mithrandir> doko_: around?
[09:39] <Mithrandir> doko_: emacs has some functions where it passes a char * and a couple of extra parameters (which aren't in the parameter list of the called function), then try to access those extra parameters in the called function.  This used to work (in dapper), but doesn't in edgy; is there a command line switch to revert to the old behaviour?
[09:40] <fabbione> Mithrandir: probably is the stack-protector that's causing the segfault?
[09:40] <Mithrandir> hmm, possibly.
[09:41] <fabbione> try to build without
[09:41] <fabbione> but the code in emacs needs fixing.. no matter
[09:41] <Mithrandir> sure, it needs fixing, but I won't do that now.
[09:42] <fabbione> oh i don't care either.. i don't use emacs
[09:42] <Mithrandir> I use it bloody all the time, but I prefer it not to crash when I close an unsaved buffer. :-P
[09:45] <Mithrandir> hooray, livefs-es seem to build properly this time.  Let's just hope they're reasonably-sized.
[09:48] <Mithrandir> mvo: what do you think of having apt-get grow a way of installing tasks?
[09:49] <mvo> Mithrandir: nice idea, I'm not sure how easy/hard this would be
[09:50] <Mithrandir> mvo: we had to cowboy livecd.sh to use aptitude rather than apt-get yesterday, but I'd actually be more comfortable with apt-get since it doesn't have this idea of "a partial solution is better than no solution" and similar, which is annoying when you want things to fail if they can't be accomplished.
[09:50] <Mithrandir> such as when you're building livefs-es.
[09:51] <mvo> Mithrandir: what was the problem with apt-get yesterday?
[09:52] <Kamion> BenC: yes?
[09:52] <Mithrandir> mvo: we had to switch to aptitude because of the recommends problem.  That is, we probably wouldn't have to, but we ended up doing it.
[09:52] <Kamion> SEJeff: the stuff Ben was working on was unrelated to the incident report you referred to
[09:52] <Kamion> SEJeff: and said incident report was unrelated to Knot 3. The reason Knot 3 is delayed was because of a live filesystem build problem discovered yesterday morning that took a while to rectify.
[09:53] <Mithrandir> fabbione: yup, it's the stack protector.
[09:53] <fabbione> Mithrandir: score
[09:53] <Kamion> infinity: alternative> yeah, could well be ...
[09:54] <mvo> Mithrandir: is the new apt recommends code buggy? is there a way for me to help debugging the problem?
[09:54] <Mithrandir> mvo: no, it's fine now after the last upload you did.
[09:54] <infinity> Kamion: Well, removing the last alternative (as would happen on a usplash upgrade) leaves a danling link, which forces manual mode.
[09:54] <Mithrandir> (afaik)
[09:55] <Kamion> infinity: right
[09:56] <Kamion> mvo: we didn't realise that (a) a suitable new apt was already there and (b) the LP patch to add the metapackages section had been applied
[09:56] <Kamion> otherwise I'd just have changed the overrides
[09:56] <mvo> Kamion: aha, ok. sorry for this communication problem then :/
[09:57] <Kamion> nah, our fault
[09:57] <infinity> mvo: Anyhow, that particular series of events did bring Colin to wonder if *-live might be better off as a task instead of a metapackage, since it's only really used by the livecd build process.
[09:58] <infinity> mvo: And updating ubuntu-meta just to mangle the livecds is a pain.
[09:58] <Mithrandir> Kamion: did you get the ubiquity patch from Riddell uploaded last night?
[09:58] <Kamion> Mithrandir: yeah
[09:58] <infinity> mvo: But we'd prefer not to use aptitude, since it does sketchy things when it can't do what you ask it to, hence Tollef's request for apt to be able to install a task.
[09:58] <Mithrandir> Kamion: thanks; I'll build kubuntu livefs-es too then
[09:58] <Kamion> Mithrandir: ubiquity 1.1.18
[10:00] <infinity> mvo: Alternately, I suppose, a new switch (aptitude --no-half-ass) to prevent it from trying half-assed solutions instead of just failing might be nice. :)
[10:00] <mvo> infinity, Mithrandir: ok, I have a look at the code in apt now
[10:01] <pitti> Mithrandir: are you satisfied with the alternate CDs, knot3-wise?
[10:01] <infinity> mvo: I don't care which interface we use (apt or aptitude) as long as it can both install tasks, and fail completely and painfully when it can't do precisely what you asked it to.
[10:02] <Mithrandir> infinity: it's probably harder to get that into aptitude due to the scoring engine.
[10:03] <Mithrandir> pitti: I'm been dug in with desktop CD bugs, but I think I am happy with alternate, yes.  If the wiki would like to answer me this century, I could give you a definitive answer.
[10:04] <pitti> Mithrandir: so, today will be live CD testing, as soon as they finally appear?
[10:04] <seb128> is current desktop CD worth testing? or a new one will be rolled and better to wait for that one?
[10:05] <zyga> morning everyone
[10:06] <Mithrandir> pitti: from the reports on the wiki, it looks like alternate is ok.  I need a couple of amd64 tests, but apart from that I'm happy.
[10:06] <Fujitsu> Morning, zyga.
[10:06] <Mithrandir> pitti: yes, live cds are building now.
[10:06] <pitti> seb128: ^
[10:06] <pitti> cool
[10:06] <Mithrandir> seb128: wait ten minutes or so
[10:06] <seb128> ok
[10:08] <Mithrandir> *sigh*
[10:08] <Mithrandir> we're oversized.
[10:08] <imbrandon> re
[10:08] <Mithrandir> Kamion: we should be able to roll back to using apt-get, shouldn't we?
[10:10] <Kamion> Mithrandir: yeah, if I make the metapackage section changes
[10:11] <infinity> Kamion: Well, you have until the next publisher run (we can do a by-hand run around :30 or :35..)
[10:12] <Mithrandir> hmm, -desktop for knot 2 didn't have evms, mdadm, etc.
[10:12] <Mithrandir> nor did it have any of the python-* and random other bits.
[10:13] <infinity> Err, when did mdadm get back in standard?
[10:13] <Mithrandir> infinity: it's not?
[10:13] <Mithrandir> it's in ship
[10:14] <infinity> Answer: It didn't, but the Packages file thinks it did.
[10:14] <infinity> Which means germinate thinks it is.
[10:14] <infinity> Which means something's gone wrong.
[10:14] <infinity> (base)adconrad@cthulhu:~/build/seeds/edgy/ubuntu$ apt-cache show mdadm | grep ^Task
[10:14] <Mithrandir> indeed.
[10:14] <infinity> Task: ubuntu-standard, kubuntu-standard, edubuntu-standard, xubuntu-standard
[10:14] <infinity> Either germinate's on crack (checking now), or the germinate->archive updating mechanism exploded at some point.
[10:16] <Kamion> infinity: I blame hppa
[10:16] <infinity> Kamion: Drop hppa from everything, then.  Yesterday.
[10:16] <infinity> Kagou: It's pretty obvious at this point that it won't release with edgy.
[10:16] <infinity> s/Kagou/Kamion/
[10:16] <Kamion> it's in a launchpad script :(
[10:16] <Mithrandir> I'm not sure why hppa is to blame, but if you say so, I guess you're right.
[10:16] <infinity> OTOH, germinate seems perfectly happy.
[10:17] <infinity> So, yeah, it's LP that's confused.
[10:17] <Kamion> Mithrandir: the ubuntu-standard metapackage on hppa still Depends: mdadm
[10:17] <infinity> Kamion: Are Task overrides not arch-specific?
[10:17] <Kamion> don't think so
[10:17] <Mithrandir> Kamion: ah, and that confuses lp.  I see.
[10:17] <infinity> That would be the issue then, yeah.
[10:17] <infinity> Well, that'll go away for now if we switch back to apt.
[10:17] <Kamion> they should be
[10:18] <Kamion> ok, I'll chase that up with team soyuz
[10:18] <infinity> Kamion: Can you get the overrides fixed ASAPish, and we can trigger a fresh publisher run?
[10:18] <Kamion> ok, give me a few
[10:19] <Kamion> just all the binaries from {,k,ed,x}ubuntu-meta, right?
[10:20] <infinity> Kamion: Should do.
[10:20] <Kamion> $ change-override.py -x metapackages ubuntu-{minimal,standard,desktop,live} {k,ed,x}ubuntu-{desktop,live} edubuntu-server
[10:20] <Kamion> done
[10:21] <Mithrandir> infinity: ok, and you'll do the necessary livecd.sh fixes?  You might need to clean up any stray locks or processes on the buildds. (sorry)
[10:21] <infinity> Mithrandir: You're still building images currently?
[10:21] <infinity> Oh, we're in queue/lock hell, right.
[10:22] <Mithrandir> infinity: I just canceled them
[10:22] <infinity> I can make that go away.
[10:22] <Mithrandir> even as fun as it is to build livefs-es, I don't see the point in building ones which I know will be useless.
[10:24] <Kamion> infinity: shall I kick off the publisher?
[10:26] <infinity> Kamion: Whenever you'd like to, sure.
[10:26] <infinity> I'm cleaning up buildds and such.
[10:26] <pitti> ah, new images on cdimage
[10:26] <pitti> Mithrandir: but it looks you are going to roll another one?
[10:27] <infinity> We are.
[10:27] <infinity> Those were oversized.
[10:27] <pitti> ok, so I'll continue my thunderbird update fun for now before starting testing them
[10:27] <Mithrandir> pitti: yes.
[10:29] <Kamion> publisher running
[10:41] <dholbach> hello!
[10:42] <dholbach> hi pitti
[10:45] <pitti> hey hey jdub!
[10:45] <Hobbsee> hey dholbach, pitti 
[10:45] <Hobbsee> hey jdub 
[10:45] <jdub> morning!
[10:45] <pitti> moin Hobbsee 
[10:45] <Fujitsu> Ji jdub.
[10:45] <Fujitsu> Hi Hobbsee!
[10:45] <Hobbsee> hey Fujitsu 
[10:46] <infinity> Argh.
[10:46] <dholbach> hiya infinity
[10:46] <Fujitsu> Yeah, hi infinity!
[10:46] <infinity> Hey.
[10:46] <jdub> Fujitsu: so, are you actually affiliated with Fujitsu?
[10:46] <Fujitsu> jdub, er... no. Blame YukiCuss for my name >_>
[10:47] <imbrandon> lol @ jdub
[10:47] <GNOMEProject> this is kinda like jenny government
[10:47] <Lathiat> haha
[10:47] <wag> There we go.
[10:47] <jdub> ha ha
[10:47] <jdub> initial nicks are elite though
[10:47] <jdub> but Fujitsu is a sweet nick
[10:47] <dubg> I doubt it.
[10:48] <jdub> imbrandon: see, that has always made me angry
[10:48] <jdub> imbrandon: i guess i should admit it to you now
[10:48] <imbrandon> jdub, heh why is that ?
[10:48] <i> <- freenode doesn't allow apostrophes
[10:48] <imbrandon> ahh yea no '
[10:48] <pitti> jdub: ` should be ok, though
[10:49] <jdub> nor domain names
[10:49] <jdub> i notice you're imbrandon.com
[10:49] <imbrandon> yup 
[10:50] <imbrandon> for the last few years atleaste, before it was Eagle ( a.k.a WalkingEagle - too full of sh*t to fly , my full blood american indian wife would call me )
[10:50] <imbrandon> ;)
[10:51] <jdub> ha ha
[10:51] <Fujitsu> I was originally wgrant... How imaginative :P
[10:51] <jdub> it is kind of odd being in a relationship marked by cultural or ethnic differences
[10:51] <jdub> for instance, pia and i
[10:51] <jdub> i'm from sydney
[10:52] <jdub> she's from yass
[10:52] <Fujitsu> Then YukiCuss decided that he wouldn't have such a boring username on his server, so looked for one for me. He had a Fujitsu 10.4GB HDD next to him...
[10:52] <jdub> it's very complicated
[10:52] <Fujitsu> Hahah.
[10:52] <Fujitsu> Yass...
[10:52] <Fujitsu> That Triple J thing was good...
[10:52] <imbrandon> yea heh jdub i feel ya there but it nice at times too , to see the "another side" of culture(s)
[10:53] <imbrandon> (even though we're divorced now *grumble* but that a whole nother story)
[10:53] <imbrandon> anyhow i'm wayyyy OT
[10:53] <jdub> yes, drinking illegally brewed alcohol and shooting street signs has been thoroughly educational
[10:53] <imbrandon> hahahahahahaha
[10:53] <Hobbsee> lol
[10:54] <Fujitsu> Lovely Yassians.
[10:54] <jdub> imbrandon: (yass is just a country town - i'm totally taking the piss for the ubuntu-au people's benefit)
[10:54] <imbrandon> ahh ;)
[10:54] <jdub> Fujitsu: itym 'yassoise'
[10:54] <Hobbsee> jdub: better from yass than from goodnight.
[10:54] <Fujitsu> Hahahh.
[10:54] <imbrandon> would be like the souther hick towns of america i am assuming from your comments ;)
[10:54] <jdub> yeha, the jjj interview was good
[10:54] <imbrandon> southern*
[10:55] <Fujitsu> I didn't record the first minute :(
[10:55] <jbailey> fabbione: Looking at the patch, are you sure that LIBDIR doesn't *also* need to be defined for some reason?
[10:55] <jdub> imbrandon: it's actually an entirely reasonable place; just gets a lot of crap.
[10:55] <imbrandon> ;)
[10:55] <Fujitsu> jbailey, that's on topic. That can't be allowed.
[10:55] <jdub> well, it's not like noofies in canada
[10:55] <fabbione> jbailey: this way works fine and tested. all packages get builded correctly
[10:55] <jdub> because they're quite obviously a different species
[10:55] <jbailey> Fujitsu: You'll notice it's midway through a conversation, and only because we left somewhere else where it would've been too close to being on topic. =)
[10:56] <jbailey> fabbione: a'ight.
[10:56] <\sh> guys, anyone running XOrg from edgy on t43 with [Radeon Mobility M300]  in xinerama mode? I see here a complete borked mouse cursor
[10:56] <fabbione> jbailey:  i didn't want to spend more time in there.. i needed something working
[10:56] <jbailey> fabbione: It's a localised sparc change.  If you want it this week, I recommend you upload it.  Otherwise it'll need to wait for next week when I'm near my gpg key.
[10:56] <fabbione> it's already uploaded
[10:56] <jbailey> Even better. =)
[10:57] <jbailey> I haven't looked recently, but I think there's still a bug from Jim Meyering that I want to deal with, and some complaints about nscd not starting because of a missing /var/run directory.
[10:57] <jbailey> So those are next week fun, too.
[10:57] <jbailey> Whee!
[10:58] <fabbione> there is also something else i want to look at
[10:58] <fabbione> i think who did change libc-other.postinstall should be cross burned alive
[10:58] <fabbione> the call to ldconfig vanished
[10:58] <jbailey> Enjoy taking me up then.
[10:58] <fabbione> so basically you install the optmized libs
[10:58] <fabbione> and you don't use them by default
[10:59] <fabbione> i fixed a similar bug in 2.3.6 but i am sure you did push it to debian
[10:59] <jbailey> Doesn't the #DEBHELPER# token cause it to get added in again?
[11:00] <fabbione> it's empty
[11:00] <fabbione> fi
[11:00] <fabbione> #DEBHELPER#
[11:00] <fabbione> exit 0
[11:00] <fabbione> fi
[11:00] <fabbione> exit 0
[11:01] <fabbione> so either you didn't call debhelper
[11:01] <fabbione> or when it's called it's too early or something
[11:06] <jbailey> Hm
[11:06] <jbailey> fabbione: You don't happen to be bored and want to look into that, do you? =)
[11:07] <infinity> Mithrandir: Kamion's publisher run is done, and the buildds are idle again, you should be good to go to spin livefses.
[11:07] <fabbione> jbailey: once i get to finish with silo i will look at it
[11:07] <\sh> I'm happy to see Mr. Linuxpriting in #ubuntu-devel :)
[11:07] <\sh> printing even
[11:07] <fabbione> jbailey: it might be for next week tho
[11:07] <fabbione> this only affects a very specific corner case
[11:07] <jbailey> fabbione: Sure.  Into next week, I can look at it too.
[11:08] <fabbione> when you install the optmized lib alone
[11:08] <fabbione> on normal installs or upgrade is fine
[11:08] <fabbione> (due to the other 34098398439843 libs calling ldconfig)
[11:09] <Mithrandir> infinity: thanks
[11:15] <mvo> janimo: good news, a full xubuntu-desktop install upgrades cleanly from dapper->edgy 
[11:21] <janimo> mvo: thanks, nice :)
[11:23] <mvo> pitti: is there a way to enforce that new restricted-modules packages are available at the same time as updated kernels (for security upgrades)? or should this be handled in the tools (update-manager/unattended-upgrades)? we currently can end up with a system without X :(
[11:23] <pitti> \sh: indeed, let's all hug tkamppeter  :)
[11:23] <mvo> if for some reason the kernel/restricted-modules are not available in the same publisher run
[11:23] <pitti> mvo: if we need a new l-r-m, there should be an ABI bump
[11:24] <pitti> mvo: i. e. we only need to make sure to publish a new metapackage when kernel and lrm are in place
[11:24] <pitti> mvo: yesterday's update was an unhappy exception, won't happen again
[11:25] <pitti> mvo: but in general (like with mozilla-thunderbird and enigmal) we can't ensure that
[11:26] <mvo> pitti: ok, well. if yesterday was a exception, then all is good. one of my machines ended up without X because it auto-upgraded itself at the wrong time.
[11:40] <Riddell> Mithrandir: is the kubuntu livefs built?
[11:46] <Mithrandir> Riddell: no, since we ended up grabbing too much due to a lp bug.
[11:46] <Mithrandir> Riddell: I'll build them once I have the ubuntu ones ready (which is about now)
[11:47] <Riddell> this knot release is cursed :)
[11:48] <Mithrandir> Riddell: let's hope (k)not. :-P
[11:48] <Mithrandir> Riddell: anyway, livefs-es building now.
[11:48] <Riddell> thanks
[11:55] <janimo> Mithrandir: after the others are done please build xubuntu as well, thanks
[11:56] <Mithrandir> hooray, smaller images again.
[11:57] <Mithrandir> please test ubuntu desktop 20060915.1
[11:57] <seb128> ok
[11:57] <Mithrandir> I'll go clean out the test grid
[11:58] <Mithrandir> janimo: will do
[12:00] <pitti> Mithrandir: but you'll leave alternate results, I presume?
[12:01] <pitti> imbrandon, Riddell: are you generally satisfied with the quality of ipodslave? what's your QA assessment?
[12:02] <imbrandon> seems to work great here, i've been using it with my ipod regularly on edgy ( and SuSE shhh just for testing )
[12:02] <imbrandon> seems solid
[12:02] <Riddell> pitti: yes, and it's more sane than someone mounting an ipod and just seeing the raw ipod files
[12:02] <Riddell> it's also the default in suse and elsewhere
[12:03] <imbrandon> yea just about everywhere but debian/ubuntu
[12:03] <pitti> Riddell: ok, that sounds good
[12:03] <Mithrandir> pitti: naturally.
[12:04] <pitti> imbrandon, Riddell: ok, approved
[12:05] <imbrandon> pitti, thanks
[12:08] <sivang> re
[12:13] <Trewas> I was trying to file a bug for network-manager but launchpad.net is saying "NetworkManager does not use Malone as its bug tracker. To report a bug about NetworkManager, please use its official bug tracker.", maybe I am blind but I don't see any indication where that is or how that should be done... or does it simply mean that I should bug upstream directly?
[12:13] <Kamion> Trewas: if your bug was found while using the Ubuntu package of network-manager, use https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs
[12:14] <giftnudel> Trewas: you need to first go to distro - ubuntu and look then for the package, not directly in launchpad.net
[12:14] <Mithrandir> Riddell: kubuntu livefs-es done; doing .isos now.
[12:14] <Trewas> Kamion, giftnudel: ok, thanks
[12:30] <Mithrandir> Riddell: your livecds are served
[12:31] <Riddell> great
[12:33] <AlinuxOS> Riddell, hello, maybe you know about it, is Georgian supported in Edgy Eft Kubuntu edition ?
[12:36] <Kamion> publisher's back on full auto
[12:36] <Riddell> AlinuxOS: supported in which way?  we have language-pack-kde-ka packs, the ttf-bpg-georgian-fonts font isn't installed by default but it's brought in at install time if there's an internet connection with the language-support-ka package
[12:37] <AlinuxOS> Riddell, the problem is that some users asked me that if they install theese packages, UI still remains english.
[12:41] <Riddell> "Error: 'ka' is not a supported language or locale"  hmm
[12:42] <Kamion> what's that from?
[12:42] <Riddell> Kamion: installing language-support-ka
[12:43] <pitti> Riddell: sounds like my bug then
[12:43] <Kamion> hmm
[12:44] <pitti> Riddell: do you have language-pack-{gnome-,}ka installed?
[12:44] <Riddell> pitti: no, I have language-pack-kde-ka-base installed
[12:45] <Riddell> pitti: ah, but that doesn't depend on language-pack-ka-base
[12:45] <Kamion> you need language-pack-ka-base for the locale
[12:45] <pitti> right
[12:46] <pitti> Riddell: this will provide /var/lib/locales/supported.d/ka
[12:46] <pitti> AlinuxOS: ^
[12:46] <Kamion> why don't the support packages depend on language-pack-*-base?
[12:47] <Kamion> I see they only Recommends: language-pack-*, so I assume there was a reason ...
[12:47] <pitti> Kamion: the reason is that people usually want only one desktop translation, but more than one input support
[12:47] <pitti> Kamion: i. e. I might want to write Russian and English text, but I still only want a German desktop
[12:48] <AlinuxOS> Oh, so it's a Pitti's bug...Oi oi oi :D
[12:48] <AlinuxOS> pitti, good morning.
[12:48] <pitti> AlinuxOS: right now it's more like a design decision
[12:48] <AlinuxOS> Riddell, Kamion GOOD morning.
[12:51] <AlinuxOS> pitti, you've right
[12:51] <AlinuxOS> what about Edgy Eft's daily packs?
[12:51] <AlinuxOS> I've installed Edgy...to continue working on 2.16 and debian-installer translation.
[12:51] <Mithrandir> mjg59: is there any way for something using usplash to tell usplash that displaying text is a bloody good idea?
[12:52] <Mithrandir> mjg59: the no-text usplash makes checking the live cds kinda useless.
[12:53] <mjg59> Mithrandir: seveas was talking about that
[12:53] <mjg59> Mithrandir: Right now, no, but it's trivial to add
[12:53] <mjg59> Just add an extra parameter to the text argument
[12:53] <Mithrandir> mjg59: or add a TEXT ON / TEXT OFF command?
[12:53] <mjg59> Or that
[12:54] <mjg59> But I think explicitly setting the priority might be saner
[12:54] <Mithrandir> I'm fine with either; let's visit that post-knot-3
[12:54] <mjg59> Sure
[12:54] <Seveas> wax on, wax off
[12:54] <Kamion> pitti: ah
[12:57] <AlinuxOS> mjg59, hello bro, is there some improvements for ttf-bpg-georgian-fonts ?I've upgraded to Edgy Eft now(for translation reasons).
[12:58] <Fade> well... this kind of sucks.
[12:59] <Fade> Hans Reiser's ex wife is missing and police have served a search warrant for their house.
[12:59] <Fade> http://cbs5.com/topstories/local_story_256204954.html
[01:03] <Fade> what a mess. :/
[01:04] <HiddenWolf> Fade: #ubuntu-offtopic please
[01:05] <mjg59> AlinuxOS: It depends on fontconfig. I'll deal with it once I have some time.
[01:06] <infinity> Seveas: Was not shipping a default splash with usplash a conscious decision, or an "oops" when doing the package split?
[01:07] <mjg59> infinity: The testcard theme is built in
[01:07] <Seveas> infinity, conscious -- the default splash was removed by mjg59 even before the split
[01:07] <infinity> Seveas: It seems to have messed up update-alternatives a bit to lose the default out from under it, and it's also a bit sketchy since usplash doesn't depend on anything that provides a splash (which means you can have it installed with no artwork, which kinda explodes)
[01:07] <infinity> mjg59: Oh, read above, then. :)
[01:08] <mjg59> Having no artwork shouldn't explode
[01:08] <seb128> Mithrandir: is keyboard not matching the locale a known issue?
[01:08] <mjg59> If the dlopen fails, it should just fall back to testcard
[01:08] <mjg59> The update-alternatives thing is probably more fun
[01:08] <infinity> mjg59: Removing the default leads to a dangling symlink which makes update-alternatives drop to manual mode.
[01:08] <Mithrandir> seb128: as in, keyboard defaulting to US American rather than whatever is closest for your language?  Yes, or at least, I've seen it too
[01:08] <Kamion> mjg59: the problem is that once the alternative is bust, installing usplash-theme-ubuntu doesn't set the alternative to the artwork you just installed
[01:08] <infinity> mjg59: And when I was in that state, I just got a black startup, no testcard.
[01:08] <mjg59> But I'm sort of lacking in time to figure out Debian weirdness...
[01:08] <AlinuxOS> mjg59, I hope you fix it before Edgy Eft final realise...because version 0.2 of ttf-bpg-georgian-fonts is without fontconfig...and BPG_Chveulebrivi contains more design errors.(It's not proportional, and its simply ugly)
[01:08] <Kamion> until you do 'update-alternatives --auto usplash-artwork.so'
[01:08] <mjg59> AlinuxOS: Yes, I know
[01:09] <Kamion> seb128: lots of keyboard configuration is a bit sketchy. File bugs on console-setup please
[01:09] <infinity> mjg59: Of course, I have other issues I'll bug you about when I'm not pretending to have a weekend.  Stuff like "when usplash is working 'correctly', I get no working consoles" and such.
[01:09] <seb128> Kamion: ok, will do, thank you
[01:10] <mjg59> infinity: Hrngh.
[01:10] <mjg59> infinity: What hardware, etc?
[01:10] <mjg59> But yeah, feel free to leave until next week
[01:10] <seb128> Kamion: I didn't open a bug on ubiquity for the timezone not being set since it happens on the liveCD itself, ubiquity looks wrong for that no?
[01:11] <infinity> mjg59: Radeon X300, Thinkpad T43.
[01:11] <infinity> mjg59: I just get black consoles.
[01:11] <mjg59> infinity: Passing vga= ?
[01:11] <infinity> mjg59: Yeah.
[01:11] <infinity> mjg59: Known?
[01:11] <mjg59> Don't do that
[01:11] <Kamion> seb128: that would be casper, but I believe there's already a bug about that; we've never set the timezone on the live CD
[01:11] <mjg59> I need to have it fall back to framebuffer mode if you're running a framebuffer
[01:11] <infinity> mjg59: Not doing that upsets me more, so I guess I'll just boot without splash.
[01:11] <seb128> Kamion: ok, thank you
[01:12] <mjg59> But yeah, that's a known regression
[01:12] <seb128> I'll get time-admin fixed to handle that correctly ;)
[01:12] <mjg59> It's easily fixed with a bit of buildsystem love
[01:12] <Kamion> seb128: there's a bug filed ...
[01:12] <mjg59> Just need to open /dev/fb0, and if that succeeds use the BOGL functions rather than the svgalib ones
[01:12] <infinity> mjg59: On the plus side, my machine's decided that both suspend and hibernate are wonderful things again.  So, congrats on that, even if you had nothing to do with it.
[01:12] <Kamion> bug 58629, if you don't have it already
[01:12] <Ubugtu> Malone bug 58629 in gnome-system-tools "time-admin crashes when selecting time-zone" [High,Confirmed]  http://launchpad.net/bugs/58629
[01:13] <seb128> Kamion: I know, I was looking at why time-admin crash, and it crashes because there is no /etc/timezone
[01:13] <Kamion> nod
[01:13] <seb128> but I was not sure if having no /etc/timezone was also a CD bug
[01:14] <Mithrandir> while I could reconfigure libc6, I think just creating the symlink as part of the cd build process might make sense.
[01:15] <mjg59> infinity: The alternative is to figure out your vesa mode and then do vbetool vbemode set whatever
[01:15] <mjg59> infinity: That should get you your framebuffers back
[01:15] <mjg59> Hm. Actually, I could just hack that into usplash.
[01:15] <mjg59> Then it'd only be radeonfb people who were upset...
[01:16] <Seveas> radeonfb == fglrx?
[01:16] <infinity> mjg59: I like the autodetect-framebuffer-then-use-bogl trick, personally.
[01:16] <mjg59> Seveas: Nope
[01:16] <mjg59> infinity: Yeah, it's the right solution
[01:16] <infinity> mjg59: We still need bogl for the PPC stuff anyway, so it sounds keen.
[01:17] <infinity> Seveas: No, it's a hideous fb driver for radeon cards that is faster than vesa but buggier than a tropical rainforest.
[01:17] <mjg59> infinity: bogl is already used on ppc
[01:17] <infinity> mjg59: Yeah, I know.  I just meant "it's not going away anytme soon because of PPC, so we may as well use it cleverly elsewhere too"
[01:17] <mjg59> Oh, yeah
[01:17] <infinity> I assume we'll use the bogl backend on hppa too, when I get around to getting a head on my hppa box.
[01:17] <Hobbsee> mjg59: are you aware that your latest commit to xserver-xorg-input-synaptics is causing a fair few people grief?
[01:17] <mjg59> infinity: Indeed
[01:18] <mjg59> Hobbsee: Given that my latest commit was aaaaaaaaaaages ago, no
[01:18] <Hobbsee> mjg59: the one about a week ago.
[01:18] <mjg59> Hobbsee: No
[01:18] <mjg59> Hobbsee: Nothing to do with me
[01:19] <Hobbsee> mjg59: interesting.  -- Matthew Garrett <mjg59@srcf.ucam.org> Mon, 7 Aug 2006 22:55:42 +0100
[01:19] <mjg59> Hobbsee: Aug != September
[01:19] <Hobbsee> er, sorry.  s/week/month/
[01:19] <Hobbsee> mjg59: hush.   i cant even tell what day of the week it is, adn i've only recently started to notice it :P
[01:19] <mjg59> Hobbsee: "grief" is a poorly defined term
[01:20] <mjg59> The absence of that patch makes it useless for anyone with ALPS hardware
[01:20] <Hobbsee> mjg59: yeah, i had a more consise description yesterday.  bug 47971
[01:20] <Ubugtu> Malone bug 47971 in xserver-xorg-input-synaptics "synaptics touch pad(laptop) clicks when i dont want it to" [Critical,Confirmed]  http://launchpad.net/bugs/47971
[01:20] <Hobbsee> right
[01:21] <mjg59> To the best of my knowledge, that patch should not affect anything with a real synaptics pad
[01:21] <rodarvus> actually, synaptics seems to work quite bad on Edgy since the beginning
[01:22] <rodarvus> I don't think its mjg59 at fault here
[01:22] <mjg59> I haven't seen the bug here
[01:22] <mjg59> If anyone can actually reproduce it and debug it, that would be nice
[01:22] <Hobbsee> right, okay then.
[01:22] <rodarvus> mjg59, synaptics is extremely sensitive in most (all?) laptops I tried here
[01:22] <Hobbsee> mjg59: how does one go about debugging the mouse going crazy?
[01:22] <rodarvus> up to a point of being unusable
[01:22] <rodarvus> (I just disable it as I don't like synaptics anyway)
[01:23] <mjg59> Hobbsee: Look at the diff between the versions. Figure out what paths the code may follow.
[01:23] <mjg59> As I said, I can't reproduce it - it seems happy on both synaptics and ALPS machines here
[01:24] <rodarvus> but again, its not mjg59 at fault (nor his patch)
[01:24] <pygi> Hobbsee, you have  a sec? :)
[01:24] <Hobbsee> pygi: sure
[01:24] <rodarvus> it was like this when I uploaded a version of synaptics straight from upstream, without any ALPS support
[01:24] <Hobbsee> mjg59: okay, cool.  i figured you'd be a first point of contact, as changelogs.u.c said you'd touched it last
[01:24] <rodarvus> and to be sincere, I'm almost sure dapper had the same behavior
[01:25] <mjg59> Hobbsee: I'm willing to believe that there's a bug in the patch, especially if downgrading to the previous version fixes it
[01:25] <Hobbsee> mjg59: right, yep
[01:25] <mjg59> But as I said, I can't reproduce it, so it's hard for me to debug it
[01:25] <Hobbsee> yeah, of course
[01:25] <Hobbsee> that's reasonable
[01:25] <infinity> Hobbsee: Give me your laptop to take to the devel summit.  I'll make someone debug it. :)
[01:26] <Hobbsee> infinity: heh.  my laptop!
[01:26] <infinity> (Of course, that'd be a bit late for edgy..)
[01:26] <Kamion> mjg59: is that radeonfb patch in the usplash bug list sane to apply, btw?
[01:26] <mjg59> Kamion: Uh. Which one?
[01:26] <infinity> Kamion: The one that patches the initramfs hook?
[01:26] <Kamion> the one that goes "did you boot with video=radeon*? ok, load radeonfb"
[01:26] <Kamion> yeah
[01:26] <mjg59> Kamion: Not to usplash, no. framebuffer loading is done by initramfs-tools now
[01:26] <infinity> Kamion: That would be a bit obsolete now for x86, but I guess it could DTRT on PPC...
[01:27] <Kamion> bug 33819
[01:27] <Ubugtu> Malone bug 33819 in usplash "add a way to use radeonfb instead of vesafb or vga16fb" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/33819
[01:27] <mjg59> Kamion: Other than that, yes, it's sane
[01:27] <mjg59> Should probably be generalised in some way
[01:27] <infinity> It *should* be generalised in the kernel.
[01:27] <infinity> I'm offended that the framebuffer drivers don't all get along.
[01:27] <Kamion> well, it's actually done by both, but yeah
[01:27] <mjg59> infinity: The kernel doesn't do module loading
[01:28] <mjg59> Kamion: Urgh, is it?
[01:28] <mjg59> Kamion: Please feel free to rip it out of usplash, then :)
[01:28] <Kamion> I assumed you'd deliberately left it in usplash to facilitate porting to Debian or something
[01:28] <infinity> mjg59: Yes, but the 15 different ways to specify that you have a framebuffer and how you want it is kinda lame.
[01:28] <mjg59> No, probably just incompetence
[01:28] <infinity> mjg59: video=driver=modenumber would be much saner.
[01:28] <mjg59> infinity: video=driver=resolution would be even better
[01:29] <infinity> mjg59: Or whatever, yes.  I think atyfb supports that.
[01:29] <Kamion> fair enough. consider it outripped
[01:29] <mjg59> The problem is that the vesa stuff is handled by the bootloader, not the kernel
[01:29] <mjg59> Well, possibly video.s, but still
[01:29] <infinity> mjg59: Actually, it seems to parse "magicnumber" or "WxHxDxR"
[01:30] <mjg59> infinity: for vesafb, I don't think it does
[01:30] <infinity> mjg59: No, I was specifically referring to atyfb there.
[01:30] <mjg59> Ah, right
[01:30] <infinity> mjg59: Refer back to my "no two drivers do it the same" thing. :)
[01:30] <mjg59> But you want a generalised solution :)
[01:30] <Kamion> oh actually no, it's the /dev/tty* setup that's done by both
[01:30] <mjg59> Which is difficult for vesafb and intelfb
[01:30] <Kamion> why is /dev/tty* done by the framebuffer hook?
[01:30] <infinity> Overzealous cutting and pasting?
[01:31] <mjg59> Can't remember
[01:31] <mjg59> Hm.
[01:31] <mjg59> To be honest, I think we should enable suspend by default on edgy
[01:31] <mjg59> It solves a couple of UI issues, and I think it'll work for enough people
[01:31] <infinity> Hey, if it works for me, it must work for everyone.
[01:32] <thom> heh
[01:32] <Mithrandir> pitti: does the desktop ppc cd reboot for you if you press a key?
[01:33] <pitti> Mithrandir: still at installation, will try once it finished
[01:33] <Mithrandir> pitti: after the check is completed, naturally
[01:33] <Mithrandir> when you get the black screen
[01:33] <pitti> Mithrandir: ah, in 'check' mode?
[01:33] <Mithrandir> yeah
[01:33] <pitti> well, I *think* I tried pressing keys, but I'll check again to be 100% sure
[01:33] <Mithrandir> thanks
[01:33] <Mithrandir> it _should_ reboot, but I could have done something wrong
[01:34] <pitti> it's setting the clock now, can't take long any more
[01:34] <doko_> tkamppeter: do you know if somebody is upgrading to the new hplip version?
[01:34] <Mithrandir> I got an emergency call from the blood donation place here and they needed people to come and give blood today, so I need to pop out for a bit.
[01:34] <Mithrandir> if somebody could please test alternate amd64 and i386 desktop, that'd be lovely.
[01:34] <Mithrandir> I'll be back in an hour or so
[01:35] <roico> hi... does any1 know if the common customizations spec is going to be implemented by edgy?.. is there any work being done on it?...
[01:48] <roico> hi... does any1 know if the common customizations spec is going to be implemented by edgy?.. is there any work being done on it?...
[01:49] <dholbach> roico: the status and whiteboard of the space in the tracker should reflect that.
[01:50] <roico> hmm. sorry for my bad english, but whats "tracker"?
[01:51] <dholbach> roico: https://features.launchpad.net/distros/ubuntu/+spec/common-customizations
[01:52] <roico> ok lol... it says: "no indication is given as to whether or not this work will be completed for the targeted release"... =\
[01:54] <roico> and there is no whiteboard...
[01:56] <Kamion> roico: so it probably won't be done for edgy
[01:56] <Kamion> I seem to remember telling you this last time you asked, also
[01:56] <Kamion> if you have further questions, you should probably ask the assignee
[01:57] <_ion> < neuralis> jdub: no worries, it just means my nick joins the ranks of kam ion, key buk, infi nity, mith randir, etc. spaces inserted to protect the innocent from their irc client beeping ;)
[01:57] <_ion> I admit: i'm guilty.
[01:58] <pitti> heno, dholbach: for the record, I have at-spi running since yesterday without any problem
[01:59] <heno> pitti: that's great! sort of ;-/
[01:59] <dholbach> pitti: I can't get it to crash neither :-/
[01:59] <pitti> dholbach, heno: is it reported to crash randomly, or on special events?
[01:59] <heno> Anyone else here on #u-dev care to test AT-SPI? 
[02:00] <heno> pitti: thanks to testing!
[02:00] <Kamion> mvo: are you aware that "translations_mutliverse_20060915.tar.gz" is misspelled?
[02:00] <dholbach> pitti: "apport shows a crash report" - my hypothesis is: it crashes on logout and apport shows on next login
[02:00] <mvo> Kamion: *gar* no, please reject
[02:00] <pitti> dholbach: 'k, will try that once this tbird build condescends to finish
[02:00] <Kamion> mvo: done
[02:01] <dholbach> pitti: I'm not sure that's really case, but it would explain a bit
[02:01] <heno> pitti: for me it seems to crash on startup and then at 4-5 random times during my day
[02:01] <pitti> heno: however, I didn't enable any additional modules like magnifier and such; shall I?
[02:01] <heno> usually when I start an application, try to print or something
[02:02] <pitti> heno: well, if you can reproduce the crash, maybe you can debug it?
[02:02] <heno> pitti: perhaps the screen reader (and turn the volume down for your sanity)
[02:03] <heno> pitti: I cannot reproduce it at will, nor seem to get a proper backtrace
[02:03] <pitti> Mithrandir: ok, so after check I can type characters and 'enter' causes a line break, but it does not reboot
[02:04] <pitti> heno: do you have debug symbols?
[02:04] <heno> pitti: no, dholbach was talking about making a debug package
[02:05] <heno> so I can try with that
[02:07] <pitti> hm, apparently not
[02:07] <heno> pitti: did you restart since activating AT-SPI? (it needs a restart to actually activate)
[02:07] <pitti> heno: yes, I activated at-spi itself already yesterday
[02:07] <heno> I guess you see it in top
[02:07] <heno> ok
[02:07] <pitti> /usr/lib/at-spi/at-spi-registryd --oaf-activate-iid=OAFIID:Accessibility_Registry:1.0 --oaf-ior-fd=27
[02:07] <AlinuxOS> pitti, re-hello is there something like deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates ./  ?
[02:07] <dholbach> heno: it seems that it crashes on logout
[02:07] <pitti> AlinuxOS: almost - s/-updates//
[02:08] <heno> dholbach: you got a crash?
[02:08] <dholbach> heno: seb128 just got one on logout (which one usually (without apport) does not notice) on #ubuntu-desktop
[02:08] <pitti> AlinuxOS: it's dapper-updates, but just 'edgy'
[02:09] <pitti> heno, dholbach: please NB that it is a SIGABRT, not a SEGV or so
[02:09] <pitti> seb128: ^
[02:09] <seb128> right
[02:09] <pitti> so a grep -r abort might help
[02:10] <seb128> grep on what?
[02:10] <pitti> maybe it just does something unusual when it's SIGTERMed at logout
[02:10] <pitti> seb128: 'abort.*\(' perhaps
[02:10] <pitti> seb128: well, the trace should tell you where it abort()ed
[02:10] <seb128> Program received signal SIGABRT, Aborted.
[02:10] <seb128> [Switching to Thread 47096792983968 (LWP 31575)] 
[02:10] <seb128> 0x00002ad59339347b in *__GI_raise () from /lib/libc.so.6
[02:10] <seb128> (gdb) bt
[02:10] <seb128> #0  0x00002ad59
[02:10] <seb128> 
[02:11] <seb128> that I know :p
[02:11] <AlinuxOS> pitti, loool I've changed dapper to edgy..and it dosen't work :) There is Edgy support yet...right ?
[02:11] <pitti> seb128: hm, the bt in #u-desktop doesn't look terribly useful
[02:11] <seb128> pitti: let me read the backlog, dunno if you speak about apport or the crash itself 
[02:11] <pitti> seb128: the crash itself
[02:11] <seb128> pitti: <seb128> dholbach: the bt has no function from it, doing debug builds now
[02:11] <pitti> ah
[02:12] <seb128> still building :)
[02:12] <pitti> seb128: this smells like something throws an unhandled exception the glib way
[02:12] <seb128> right
[02:13] <Kamion> mjg59: should /lib/libusplash.so.0 be given a SONAME? (lintian complains that it doesn't have one)
[02:14] <tkamppeter> doko_, I have only made an UVF ER for HPLIP 1.6.7 (sent to pitti and mdz) but I did not get any answer yet.
[02:14] <mjg59> Kamion: Oh, erm, yes.
[02:15] <mjg59> Kamion: Right now we're making no ABI (or even API) guarantees - should I bump the SONAME every time, or just leave it at .0 and handle transitions by hand?
[02:15] <mjg59> There's only one other package that uses it
[02:16] <doko_> tkamppeter: where are the packages?
[02:17] <seb128> dholbach, pitti: new backtrace:
[02:17] <seb128> Program received signal SIGSEGV, Segmentation fault.
[02:17] <seb128> [Switching to Thread 47008438825168 (LWP 28822)] 
[02:17] <seb128> 0x00002ac0fe705102 in get_c_method (obj=0x556920, class_id=1, servant=0x7fffacf64020, method_offset=16, method_flags=0)
[02:17] <seb128>     at poa.c:2562
[02:17] <seb128> 2562            if (!obj ||
[02:17] <seb128> (gdb) bt
[02:17] <seb128> #0  0x00002ac0fe705102 in get_c_method (obj=0x556920, class_id=1, servant=0x7fffacf64020, method_offset=16, 
[02:17] <seb128>     method_flags=0) at poa.c:2562
[02:17] <seb128> #1  0x00002ac0fe7052ab in ORBit_c_stub_invoke (obj=0x556920, methods=0x2ac0fe5b1248, method_index=1, ret=0x0, args=0x0, 
[02:17] <seb128>     ctx=0x0, ev=0x7fffacf640c0, class_id=1, method_offset=16, 
[02:17] <seb128>     skel_impl=0x2ac0fe4a3210 <_ORBIT_skel_small_Bonobo_Unknown_unref>) at poa.c:2615
[02:17] <seb128> #2  0x00002ac0fe4a4a48 in Bonobo_Unknown_unref () from /usr/lib/libbonobo-activation.so.4
[02:17] <seb128> dwarf2_read_address: Corrupted DWARF expression.
[02:17] <seb128> not really useful :/
[02:18] <Kamion> mjg59: leave it at 0, I guess, although I can never remember what the rules are for SONAME 0
[02:18] <seb128> what is that "Corrupted DWARF expression"?
[02:18] <dholbach> I read it somewhere else already and it was not the problem that time, but I have no idea either
[02:18] <Kamion> mjg59: don't all of usplash-theme-ubuntu (ngh misnaming), kubuntu-artwork-usplash, xubuntu-artwork-usplash use it?
[02:19] <pitti> seb128: that looks bogus anyway; if (!ptr) shouldn't crash
[02:19] <tkamppeter> doko_, before anyone starts to package we should at first determine whether we have agreement to put them into Edgy, otherwise we could package directly HPLIP 1.6.9 after the Edgy deadline.
[02:19] <pitti> seb128: however, the part after the || might be the interesting one
[02:19] <seb128> right
[02:19] <pitti> seb128: since obj != NULL, thus the || is evaluated
[02:19] <tkamppeter> Debian packages are there, see bug 51573.
[02:19] <Ubugtu> Malone bug 51573 in Baltix "Please update HPLIP to 1.6.7" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51573
[02:20] <seb128> pitti, dholbach: the abort one: http://paste.ubuntu-nl.org/23513
[02:21] <doko_> tkamppeter: no, that's not the way it works. we'll have to make the package, and then see, if it works. before, there's no fact you can base a decision on.
[02:22] <dholbach> seb128: I'm quite clueless on it
[02:22] <seb128> dholbach: me too
[02:23] <dholbach> I wonder what 'dead object' it refers too
[02:23] <AlinuxOS> pitti, loool I've changed dapper to edgy..and it dosen't work :) There is Edgy support yet...right ?
[02:23] <dholbach> i'm likely to believe upstream when they say "at-spi-registryd crashing is not the root cause" - but debugging orbit is no fun
[02:23] <pitti> AlinuxOS: yes, there are edgy langpacks
[02:24] <pitti> AlinuxOS: do you have language-pack-ka and language-pack-gnome-ka installed?
[02:24] <seb128> dholbach: right
[02:24] <dholbach> i'm out for lunch
[02:24] <dholbach> i'll have another look later on
[02:24] <Kamion> oh dear god
[02:24] <dholbach> thanks a lot seb128 and pitti
[02:24] <Kamion> I hope nobody's using hunglish on Ubuntu
[02:25] <seb128> dholbach: np
[02:26] <AlinuxOS> pitti, yes.
[02:27] <AlinuxOS> #deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates ./ is it right repository ?
[02:27] <AlinuxOS> I've changed dapper to edgy.
[02:28] <pitti> heno: hm, screen reader is marked as 'not available' in gnopernicus
[02:28] <pitti> heno: and now I have a big white rectangle in the upper left screen corner which doesn't do anything and does not go away; but no crash
[02:29] <pitti> heno: (the rectangle might be a non-working magnifier)
[02:30] <heno> pitti: yes, welcome to the world of Linux magnification :) 
[02:30] <heno> That needs some serious love
[02:30] <pitti> heno: (yup, killall magnifier killed it)
[02:30] <heno> pitti: try running Orca instead of gnopernicus
[02:30] <_ion> alinuxos: See http://people.ubuntu.com/~pitti/langpacks/daily/
[02:31] <Mithrandir> pitti: *grumble*; ok.
[02:32] <pitti> heno: oh, screen reader works now
[02:32] <pitti> heno: my computer talks to me :)
[02:32] <heno> ubuntu-desktop no longer depends on gnopernicus. Why does everyone still have it installed on Edgy?
[02:32] <heno> pitti: :)
[02:32] <seb128> because package are not automatically removed?
[02:33] <heno> does something else pull it in?
[02:33] <heno> seb128: right, ok
[02:33] <pitti> heno: it's a fairly hacked up system without u-desktop; I'll reinstall it soon
[02:33] <heno> I see
[02:33] <pitti> ok, I'm going to do an amd64/alternate test install, since Mithrandir still needs that AFAIK
[02:34] <Mithrandir> pitti: thanks.
[02:35] <Mithrandir> Riddell: how is your kubuntu testing coming along?
[02:35] <Mithrandir> janimo: you're getting desktop ISOs now, fyi.  Sorry it's taken a bit.
[02:36] <Mithrandir> hmm, somebody have an idea what I should do about edubuntu?  I can't usefully test them here and ogra's not around.
[02:36] <pygi> Mithrandir, what testing do you need?
[02:38] <Mithrandir> pygi: https://wiki.ubuntu.com/Testing/Current is the procedure
[02:38] <pitti> dholbach: so, the bt looks a bit like an unexpected closing of something at-spi communicates with and exchanges corba data
[02:39] <pitti> dholbach: maybe if that program is killed first, at-spi falls over; if at-spi is killed first, it works
[02:39] <pitti> unserialization bugs make little sense otherwise in that form
[02:40] <pitti> dholbach: oh, hm, it's a serialization crash, not unserialization
[02:40] <Riddell> Mithrandir: all six kubuntu CDs are good to go
[02:40] <Mithrandir> Riddell: yay, goodie.
[02:40] <Hobbsee> yay :)
[02:40] <pitti> Mithrandir: can you please add your test results as well so that we see what's still missing?
[02:40] <Riddell> Mithrandir: usplash is broken in various places and the accessibility settings don't seem to work but I'm happy for a Knot
[02:41] <Mithrandir> pitti: I did that two minutes ago.
[02:41] <pitti> oh, /me reloads
[02:41] <Mithrandir> seb128: did you ever complete your desktop install?
[02:41] <Mithrandir> Riddell: yeah, I need to start writing the release notes now.  Input, as always, welcome.
[02:42] <Riddell> Mithrandir: https://wiki.kubuntu.org/EdgyEft/Knot3/Kubuntu for us
[02:42] <Kamion> pitti: did you ever request a sync / do a merge of the new latex-ucs?
[02:42] <pitti> Kamion: AFAIK I requested a sync
[02:42] <Riddell> Mithrandir: but a big caveat to be patient on bootup because usplash might not work and upstart doesn't give any output would be essential :)
[02:42] <seb128> Mithrandir: yep, just did an i386 install with custom partitionning, I was about to update the wiki, worked fine
[02:43] <Kamion> pitti: ok, thanks
[02:43] <pitti> Kamion: bug 59865
[02:43] <Ubugtu> Malone bug 59865 in latex-ucs "[after knot3 freeze]  Please sync latex-ucs (main) from unstable (main)" [Untriaged,Confirmed]  http://launchpad.net/bugs/59865
[02:43] <Mithrandir> seb128: ok, thanks.
[02:43] <Kamion> righto, good
[02:43] <Kamion> trying to blitz through stuff depending on console-data
[02:43] <Kamion> system-config-kickstart's dependency is a bit hard to kill though
[02:43] <seb128> Mithrandir: liveCD had non-azerty keymap while I picked french, mono is broken by that unionfs path issue and time-admin crash due to no /etc/timezone, out of that it worked fine
[02:44] <Kamion> seb128: first problem known, I'm working on it
[02:44] <Mithrandir> seb128: all should be fixed for beta, none are blockers for knot 3
[02:44] <seb128> Kamion: ok, cool
[02:44] <pitti> ok, CD burned, going offline for amd64/alternate test install
[02:44] <seb128> Mithrandir: right
[02:44] <Mithrandir> (and I want to call this a weekend soon)
[02:47] <Mithrandir> janimo: your ISOs are served.
[02:48] <janimo> Mithrandir: thanks
[02:50] <Mithrandir> seb128: we're at GNOME 2.16 proper now, right?
[02:50] <seb128> Mithrandir: correct
[02:52] <Mithrandir> Riddell: do you have a single Kubuntu-specific knot-2-to-knot-3 change you want me to highlight in the announcement?
[02:53] <Riddell> Mithrandir: Konversation 1.0 would be nice to point out, since they were good enough to schedule their release cycle around us
[02:54] <seb128> CD testing, brb
[02:54] <janimo> Mithrandir: for xubuntu the only change I can think of is the upgrade of the core Xfce apps to 4.4 RC1
[02:55] <Mithrandir> janimo: ok, I'll include that
[02:57] <Mithrandir> http://err.no/tmp/knot-3.txt ; corrections, etc welcome.
[02:58] <Kamion> ... apparently so
[02:58] <Mithrandir> janimo: we expect 4.4 release to happen for edgy, right?
[02:58] <janimo> Mithrandir: yes. But we expected that for dapper as well so I am not 100% sure :)
[02:59] <janimo> their original target was Dec 2005 :)
[02:59] <Mithrandir> janimo: heh, ok
[02:59] <Kamion> Mithrandir: worth mentioning the replacement of the console layer maybe?
[03:00] <Mithrandir> Kamion: true, added.
[03:01] <Mithrandir> janimo: for beta, you might want to have a page similar to  http://www.ubuntu.com/testing/knot3 or https://wiki.kubuntu.org/EdgyEft/Knot3/Kubuntu to link to.
[03:04] <janimo> Mithrandir: ok
[03:04] <Mithrandir> janimo: just a suggestion, it's obviously up to you.  :-)
[03:06] <janimo> Mithrandir: I'll pass it on to some documentation/graphics people :)
[03:07] <janimo> there was such a presentation for dapper IIRC so they may write one up nw as well
[03:07] <janimo> iwj: how easy is setting the default firefox theme ( I just saw in the announcement that it's tangerine now)
[03:08] <janimo> if it is reasonably easy to override it I'd like to set it to tango for xubuntu as that's what the rest of the desktop uses
[03:11] <AlinuxOS> doko, ping
[03:12] <AlinuxOS> doko, I've upgraded to Edgy, installed your repo, everything is ok... but I can't find openoffice.org-experimental package. Even openoffice.org-l10n-ka is not available.
[03:13] <giftnudel> Mithrandir:  "The primary changes from Knot2 have finalising ...." <-  there is probably a "been" missing
[03:15] <Mithrandir> giftnudel: point, fixed.
[03:16] <giftnudel> rest sounds good to me
[03:17] <Mithrandir> goodie.
[03:17] <Mithrandir> I'll just wait for pitti to return and confirm amd64/alternate is good before publishing, then
[03:23] <sladen> seb128: any idea how I tell gnome-something to stop wanking with the X keyboard settings?
[03:23] <seb128> sladen: don't start gnome-settings-daemon
[03:24] <seb128> sladen: maybe unset the gconf keys for /desktop/gnome/peripherals/keyboard/kbd/*
[03:25] <seb128> /desktop/gnome/peripherals/keyboard/kbd/layouts and /desktop/gnome/peripherals/keyboard/kbd/options and maybe /desktop/gnome/peripherals/keyboard/kbd/model
[03:25] <seb128> sladen: but if your issue happens on gdm that's not due to GNOME
[03:27] <sladen> seb128: /doesn't/ happen on just X+xterm.  /doesn't/ happen on gdm.  /does/ happen with GNOME has started.  killing g-s-d does not revert it
[03:27] <seb128> sladen: sure, killing g-s-d doesn't happen any different setting
[03:27] <sladen> seb128: I'll try that
[03:28] <seb128> s/happen/apply
[03:28] <seb128> sladen: basically g-s-d does setxkbmap
[03:28] <seb128> with the gconf options I pointed
[03:34] <iwj> janimo: It's quite straightforward.  The theme package drops a *.js file in /etc/firefox/pref.
[03:34] <iwj> janimo: If you want to change it for xubuntu only that's slightly more tricky.
[03:35] <iwj> Because xubuntu installs the firefox-themes-ubuntu package, right ?
[03:46] <Kamion> seb128: is bug 60516 yours or mine?
[03:46] <Ubugtu> Malone bug 60516 in ubiquity "Time zone & locale should also affect Gnome time applet 12/24 preference" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60516
[03:49] <seb128> Kamion: the 12/24 informations comes from the locale, I would say it's a locales bug
[03:51] <janimo> iwj: yes, I want it to change in a default install not by the user after install
[03:52] <janimo> iwj:  currenly the firefox theme package is not part of xubuntu
[03:52] <iwj> janimo: Right.  Perhaps we'll have to move the default theme setting from firefox-themes-ubuntu to some other package.
[03:53] <iwj> janimo: But it's the one with the tango firefox theme so if you want that in ff you'll have to install it.
[03:53] <janimo> iwj: will this involve the alternatives system?
[03:53] <iwj> That doesn't seem like the right anser.
[03:53] <iwj> s/ans/&w
[03:53] <janimo> iwj: sure I wiull install it, it's just today that I noticed it is in main and in ubuntu
[03:53] <iwj> I'm afraid I'm totally unfamiliar with the set of artwork etc. packages.
[03:53] <janimo> iwj: I am glad, I don;t like alternatives in packaging :)
[03:53] <iwj> But what we need is for the default theme setting for each distro to be in a package specific to that distro.
[03:54] <janimo> iwj: what happens when both ubuntu-desktop and xubuntu-desktop are installed?
[03:54] <iwj> So the theme setting for firefox should move out of firefox-themes-ubuntu into some other package which is only in ubuntu and not {x,k,ed}ubuntu.
[03:54] <iwj> Well, you'd end up with one at random.  I don't know what order ff reads the files in /etc/firefox/pref.
[03:54] <janimo> iwj: if firefox can start with whatever it finds first ok
[03:55] <janimo> iwj: that's ok as long as ff does not expect a specific file name then
[03:55] <iwj> Maybe it reads them in a predictable order (eg, based on filename) in which case you could control which one wins.
[03:55] <iwj> Indeed, you can have as many files in there as you like.
[03:57] <bddebian> Heya folks
[04:04] <janimo> iwj: looks like this package installs a symlink called theme.js to theme-actual.js
[04:04] <janimo> does ff look for theme.js?
[04:07] <iwj> janimo: ff reads all files ending in .js.
[04:07] <iwj> The reason for the symlink is so that the file is disabled when the package is deinstalled but not purged.
[04:10] <janimo> ah, so since it sources all files even multiple settings of selectedSkin() are ok.
[04:10] <pitti> ok, test installs worked as expected
[04:14] <Mithrandir> pitti: yay, that means we can release.
[04:21] <iwj> janimo: Yes, but if you put more than one file in there we don't know which one will get used.
[04:21] <iwj> I haven't looked through the code to see what it does ...
[04:21] <Nafallo> yay!'
[04:21] <iwj> I wouldn't be surprised if it just processes them in readdir order.
[04:22] <tseng> Mithrandir++
[04:27] <janimo> iwj: so looks like I could just install thias package and drop in the same dir a file which has a higher priority (aftre figuring out the rules)
[04:28] <janimo> that file can reside in xubnutu-default-settings so ne new packages need to be crated or ubuntu ones altered
[04:28] <janimo> but this means that whenever xubuntu-settings is installed the tango theme takes precedence
[04:29] <janimo> I hope the order is not affected by underlying filesystem or other things beyond our control
[04:30] <Mithrandir> janimo: are you happy with your ISOs?  (as in, should I release them?)
[04:30] <janimo> Mithrandir: just tested one in qemu, looks ok
[04:31] <janimo> not much changed since sep11 when I installed the daily on my box
[04:31] <janimo> so yes, please release
[04:31] <Mithrandir> janimo: ok, willdo
[04:32] <iwj> janimo: underlying filesystem> That's what I meant by readdir order.
[04:33] <iwj> janimo: it would be better to avoid relying on this, also for the other reason you mention.  So instead the theme setting should be moved out of firefox-themes-ubuntu to another package but you should probably consult the artwork list to ask which package.
[04:36] <janimo> iwj: ok, will do
[04:59] <iwj> janimo: Yes, that would be my guess but I think someone who actually knows should tell us :-).
[05:01] <janimo> iwj: I talked to dholbach in ubuntu-desktop
[05:01] <iwj> janimo: Aha.
[05:01] <janimo> he agreed it can be moved to human-theme
[05:01] <iwj> Right, sounds fine to me.
[05:01] <dholbach> yeah, just go ahead - that's fine
[05:01] <janimo> if the file name is to be kept across packages we'd need conflict/replaces
[05:02] <janimo> could we not avoid that by calling them differently now
[05:02] <dholbach> and probably depends
[05:02] <janimo> like ubuntu-theme
[05:02] <dholbach> so the prefs file is not installed without the .jar file
[05:02] <janimo> since ff sources any .js it does not have to be afixed name
[05:02] <janimo> dholbach: depends are fine
[05:02] <dholbach>  cool
[05:02] <iwj> You should move the theme.js-actual file to the new package with a Replaces.  The symlink should stay in the firefox-themes-ubuntu package.
[05:02] <janimo> I just dont; like conflict/replaces :)
[05:02] <iwj> That way the theme.js-actual file will be ignored when the theme isn't installed.
[05:04] <janimo> dholbach: depends would mean human-them indirectly deps on firefox is that ok? (for epyphany lovers :) ?
[05:05] <dholbach> oh man, really?
[05:05] <Mithrandir> maswan: if you're around, could you do an extra mirroring run for knot 3?
[05:05] <janimo> the theme package deps on ff
[05:05] <dholbach> that makes no sense
[05:05] <dholbach> we should drop that depends
[05:05] <dholbach> ROCK ON!
[05:06] <Mithrandir> :-)
[05:06] <Mithrandir> yay us
[05:06] <dholbach> janimo: we should drop that depends in f-t-u
[05:06] <janimo> we could just recommend and check for the existence of /etc/firefox/prefs in the install scripts
[05:06] <Mithrandir> once we have a couple of mirrors with the stuff, I'll send out the release announcement
[05:06] <janimo> dholbach: I agree but this is no longer my decision to make
[05:06] <dholbach> janimo: or recommends firefox
[05:06] <rodarvus> hooray!
[05:06] <janimo> I just want tango theme for xubuntu, not mucking too much with the insides of ubuntu-deskotp
[05:07] <janimo> stepping on toes and all that
[05:07] <Mithrandir> edgy is frozen until somebody who has a small duckie thaws it, though. :-P
[05:07] <dholbach> janimo: just move it from depends to recommends - I'll write a mail to iwj, fschoep, you and me
[05:08] <janimo> dholbach: so the current theme package should recommend firefox, and get the .js removed
[05:08] <dholbach> yeah
[05:08] <dholbach> that makes sense
[05:08] <janimo> then human theme get that removed file and add a replaces
[05:08] <janimo> ok
[05:08] <dholbach> and a depends on the f-t-u
[05:08] <janimo> right
[05:08] <rodarvus> Mithrandir, http://cdimage.ubuntu.com/releases/edgy/knot-3/ is still empty, though?
[05:09] <Keybuk> Mithrandir: should I release everything from unapproved ?
[05:13] <dholbach> janimo: hum - what about people install f-t-u and expecting firefox to pick the theme up?
[05:19] <Keybuk> Mithrandir: thawed (via malcc)
[05:19] <imbrandon> Mithrandir, so no uploads to main quite yet ?
[05:19] <imbrandon> err Keybuk ;)
[05:20] <janimo> dholbach: they install those as a convenience (jsut as if they had downloaded them off the net)
[05:20] <janimo> the decision of which is the default is a separate step
[05:20] <dholbach> ok
[05:20] <janimo> especially since that package has 3 themes
[05:20] <maswan> Mithrandir: running
[05:21] <janimo> dholbach: anyway we want to make sure this work in default x/ubuntu desktop installs, not when the user does manual installs/removals
[05:21] <janimo> in the latter case the user knows better 
[05:21] <dholbach> janimo: mailed
[05:28] <janimo> dholbach: is f-t-u packaging maintained in bzr as well? it has a .bzr dir
[05:28] <dholbach> might be that fschoep has it in bzr too
[05:28] <janimo> he does accoring to a chlog entry
[05:28] <dholbach> cool
[05:29] <janimo> but I was not sure if it's a regular apt-get source or bzr upadte type package
[05:29] <janimo> and still am not sure :)
[05:32] <janimo> hmm this has a very unusual packaging system
[05:33] <Mithrandir> Keybuk: yes, please.  And thanks.
[05:33] <Mithrandir> rodarvus: it takes a little bit of time to sync 3x4x700MB, even over a fast connection. :-)
[05:34] <rodarvus> :)
[05:34] <imbrandon> Mithrandir, main un-thawed ? 
[05:34] <Mithrandir> imbrandon: 17:19 < Keybuk> Mithrandir: thawed (via malcc)
[05:34] <Mithrandir> imbrandon: so yes.
[05:34] <imbrandon> kk
[05:34] <imbrandon> makin sure ;)
[05:42] <jono> mako, ping
[05:42] <jono> bugger he isnt here
[05:48] <dholbach> jono: according to his blog entry he's in Berlin at Wizards of OS
[05:48] <jono> ahhh of course
[05:50] <phanatic> jono: hi, is there any deadline for sponsorship requests for uds?
[05:51] <jdub> jono: http://reverendted.wordpress.com/2006/09/15/opensuse-about-to-overtake-ubuntu-on-distrowatch-7-day-hpd-chart/
[05:51] <jdub> ^ ha ha
[05:51] <Keybuk> it's done it once before
[05:52] <jdub> for some reason, i enjoy watching the novellians stewing over ubuntu.
[05:53] <jono> phanatic, not at the moment
[05:53] <jono> jdub, hehe
[05:53] <phanatic> jono: so it's also unknown when they are gonna be announced?
[05:54] <jono> phanatic, yeah, I am working on this now :)
[05:55] <Frederick> Folks I apologize to ask it here but the chances someone used imagemagick here is much greater than in #ubuntu or #kubuntu foks anyone else here having problems to debug aplications wich use magick core and magick wand? I cant debug them on gdb nor ddd Ive tried https://wiki.ubuntu.com/Backtrace with no luck. It lacks the dbg package =/
[05:55] <Keybuk> jdub: nothing wrong with novellians ;)
[05:55] <Keybuk> Frederick: actually, the chances are somewhat less
[05:55] <phanatic> jono: thanks :) i was just asking because of visa issues...
[05:55] <jono> phanatic, sure, I will try and get an answer out over the next few days :)
[05:55] <Frederick> Keybuk, why? :-/ Developers usually play around more with libs than ordinary users :P
[05:56] <phanatic> jono: great :)
[05:56] <Keybuk> Frederick: I don't think that's true at all.  users play around with things more than developers, who are too busy fixing things to play
[05:56] <Frederick> oki...
[05:57] <bddebian> Oh man Frederick is back again?? :-)
[05:57] <Frederick> bddebian, yep helo and thanks for the help yesterday
[06:04] <Kamion> infinity: could you investigate why all the console-data 2:1.0-2ubuntu3 binary uploads failed, please? it looks like either a soyuz bug or a buildd bug
[06:04] <Kamion> oh, hmm, actually - may be a debian/rules bug
[06:05] <Kamion> hand-rolled dpkg-distaddfile stuff for udebs, probably doesn't account for epochs
[06:11] <HiddenWolf> How long has the knot been out? :)
[06:11] <HiddenWolf> Ah. I'm a full hour late.
[06:24] <bluefoxicy> HiddenWolf:  shush.  Just go play with it ;)
[06:24] <HiddenWolf> bluefoxicy: I'm running it, I just wanted to be the first seeder to make my ISP suffer a bit. 
[06:25] <HiddenWolf> bluefoxicy: Uploaded 55GB for knot 2, planning to top that. ;)
[06:25] <bluefoxicy> ah, giving everyone a chance to try the knot
[06:25] <bluefoxicy> dad wants me to clean my room today :/
[06:28] <tkamppeter> I am trying to build a package of HPLIP 1.6.7 and get
[06:28] <tkamppeter> error: linux/compiler.h: No such file or directory
[06:29] <pitti> tkamppeter: so, it seems to be time to upload gutenprint \o/
[06:29] <tkamppeter> How do I obtain this file (probably /usr/include/linux/compiler.h)?
[06:29] <tkamppeter> Which BuildDependency is missing?
[06:30] <tkamppeter> pitti? How does the upload work? Will you upload it? Or do I have to do so? And to where?
[06:30] <zul> tkamppeter: its a bogus error you can just remove the line
[06:30] <pitti> tkamppeter: you can't, I'll do it
[06:31] <tkamppeter> zul, which line?
[06:31] <zul> pitti: uploaded linux-source-2.6.10
[06:31] <zul> pitti: er...2.6.12
[06:31] <pitti> zul: to jackass, or to your computer?
[06:31] <janimo> zul: are you planning libvirt and other userspace xen stuff or just kernel for edgy?
[06:32] <imbrandon> Kamion, ping
[06:32] <tkamppeter> For me it is somewhat strange, Mandriva has /usr/include/linux/compiler.h in glibc-devel, Ubuntu does not have the file at all.
[06:33] <zul> pitti: jackass
[06:33] <seb128> tkamppeter: linux-headers-2.6.17-7: /usr/src/linux-headers-2.6.17-7/include/linux/compiler.h
[06:33] <zul> janimo: yeah i was looking into it this morning already have it downloaded
[06:33] <pitti> zul: nice that it works again; oh, right, I got failed build logs for sparc and hppa
[06:34] <zul> pitti: aie..
[06:34] <pitti> tkamppeter: usually you should avoid depending on linux-headers; that smells fishy
[06:34] <pitti> tkamppeter: gutenprint uploaded; happy bug closing!
[06:34] <janimo> zul: nice. I saw those mentioned in the FC6 test3 announcement
[06:34] <zul> janimo: ditto
[06:34] <pitti> zul: thanks
[06:35] <zul> pitti: can you forward me the sparc logs?
[06:35] <pitti> zul: these arches fail for ages now; if you are interested, I send you the logs
[06:35] <jordi> mvo: ping
[06:35] <pitti> zul: sent
[06:35] <zul> thanks...im just curisous
[06:35] <imbrandon> eer i guess Kamion or Keybuk ping heh
[06:36] <zul> pitti: sparc failed for breezy
[06:37] <Keybuk> imbrandon: ?
[06:37] <imbrandon> Keybuk, can you manualy promote libnjb please , pitti said poke you when i uploaded amarok that needed it , its been approved at https://wiki.ubuntu.com/MainInclusionReportLibnjb
[06:37] <seb128> BenC, crimsun: could you have a look on https://launchpad.net/distros/ubuntu/+source/rhythmbox/+bug/60563 please (rhythmbox freeze after linux update on dapper) and let me know what could be useful for you to determine what change could have done that?
[06:37] <Ubugtu> Malone bug 60563 in rhythmbox "freezes on startup, worked before update on 14/09/2006" [Untriaged,Needs info]  
[06:38] <zul> janimo: im going to take a run at them this weekend, basically its on my todo list
[06:38] <tkamppeter> seb128, this package I have installed, but HPLIP does not find compiler.h
[06:38] <imbrandon> Keybuk, i just uploaded amarok_1.4.3-oubuntu4 that build-deps on it
[06:38] <imbrandon> s/o/0/
[06:38] <tkamppeter> pitti, thanks for the upload.
[06:38] <pitti> tkamppeter: no problem, thanks for the merge
[06:39] <pitti> tkamppeter: so, we'll also get a new hplip and also a new foomatic?
[06:39] <janimo> Keybuk: when you have time can you look at python-cups and system-config-printer in NEW?
[06:42] <tkamppeter> foomatic-db and foomatic-db-hpijs I will do next week.
[06:42] <pitti> tkamppeter: next week I'll try and fix the last two known cups permission bugs
[06:43] <pitti> tkamppeter: after we fixed them (log files and lpd backend) it should be pretty much transparent again
[06:43] <tkamppeter> pitti, when you do that, do not forget to apply the patches which fix bug 59542.
[06:43] <Ubugtu> Malone bug 59542 in cupsys "cupsd monopolizes CPU" [Unknown,Unknown]  http://launchpad.net/bugs/59542
[06:44] <pitti> tkamppeter: no, I'll also pick up some fixes from Debian's svn head
[06:44] <pitti> tkamppeter: (changed the bug to jump on me when I do bugfixing)
[06:44] <buzzen> is anyone here who deals with raid / initramfs ?
[06:45] <Keybuk> janimo: dude, they've been in there for a couple of days!  nag when they're been in new for a couple of _weeks_!
[06:45] <BenC> seb128: Replied to bug report
[06:46] <seb128> BenC: thank you
[06:46] <janimo> Keybuk: ok. I thought that archive Fridays were exception or something :)
[06:46] <Keybuk> Friday is Kamion's day
[06:47] <janimo> besides for these I'd rather not wait weeks as they should go to main and on the xubun CD if all goes well
[06:47] <janimo> ah right.
[06:47] <jordi> Riddell: onboard has been imported in rosetta now
[06:49] <tkamppeter> pitti, zul, how to proceed with HPLIP now?
[06:54] <jdub> mjg59: i copied 13-855-resolution-set.sh to 13-915-resolution-set.sh and changed the binary names it references
[06:54] <pitti> tkamppeter: merge from Debian?
[06:55] <jdub> mjg59: and btw:
[06:55] <jdub> $ find /etc/acpi/ | grep 855
[06:55] <jdub> /etc/acpi/resume.d/13-855-resolution-set.sh
[06:55] <jdub> /etc/acpi/resume.d/49-855-resolution-set.sh
[06:55] <jdub> what's with both?
[06:55] <pitti> tkamppeter: first you should check whether merges.ubuntu.com did something sensible
[06:57] <tkamppeter> Yes, it is a merge from Debian, and I have checked merges.ubuntu.com. I have taken out patch 50 and 60, as there is no support page in the Toolbox any more, but this does not matter to our problem.
[06:57] <mjg59> jdub: Nngh. 915resolution is supposed to have that script in it.
[06:57] <tkamppeter> The BuildDependencies from Ubuntu were stricter, so I have taken these.
[06:58] <mjg59> jdub: They're both there because it's not entirely clear when it needs to be done
[06:58] <jdub> mjg59: ah.
[06:58] <jdub> heh
[06:58] <mjg59> jdub: So we do it both before and after POSTing, in case the POSTing requires the mode to be there
[06:58] <tkamppeter> s/60/55/
[06:58] <buzzen> how are you supposed to upgrade mdadm for example, when it's install script wants to do a /etc/init.d/mdadm stop - and when you boot from a raid array (which you cant just "stop)
[06:58] <buzzen> ?
[06:59] <buzzen> that seems broken
[06:59] <jdub> mjg59: figure i better copy that one for 915 too, then
[06:59] <tkamppeter> Patch 40 and 60 disappeared in the merge as they were accepted upstream according to the ChangeLog.
[07:00] <mjg59> Sigh.
[07:00] <mjg59> How can I figure out who did the merge?
[07:01] <bddebian> mjg59: If it was a merge it should have the persons name in the changelog
[07:01] <mjg59> No, it's just been synced
[07:01] <mjg59> With all Ubuntu changes dropped
[07:01] <bddebian> What package?
[07:01] <mjg59> 915resolution
[07:02] <pitti> mjg59: you can look for closed ubuntu-archive bugs against that package
[07:02] <bddebian> aye, or look at who "modified" the upload
[07:02] <ogra> knot3 released ? there is nothing on ubuntu-devel-announce
[07:02] <Kamion> ogra: yeah, I think Tollef's just waiting for mirrors
[07:03] <ogra> ah, k
[07:03] <ogra> what did you do with edubuntu ? 
[07:03] <Kamion> released it
[07:03] <ogra> cool :)
[07:03] <Kamion> we figured it probably wasn't *that* brittle considering how little was changed
[07:03] <Kamion> if it breaks, well ... sorry :)
[07:03] <ogra> i just found out that 80% of the known bugs are caused by a bashism ... :/
[07:04] <ogra> i could have easily avoided it ...
[07:04] <Kamion> mjg59: https://launchpad.net/distros/ubuntu/+source/915resolution -> "Steffen Joeris"
[07:04] <ogra> but well, i'll upgrade the package and users can grab the upgrade ...
[07:04] <mjg59> Kamion: That's the Debian maintainer
[07:05] <Kamion> so it is
[07:05] <Kamion> the most recent sync was an autosync
[07:05] <mjg59> There were Ubuntu-specific changes in the old version
[07:05] <Kamion> or maybe not
[07:05] <Kamion> I'm so confused
[07:05] <mjg59> Looks like there's only been one sync from Debian
[07:08] <LaserJock> mdz: got a minute?
[07:08] <tkamppeter> pitti, any idea for HPLIP?
[07:09] <Keybuk> rodarvus: a word ...
[07:09] <elmo> is using /usr/lib/firmware/$(uname -r) an ubuntu specific thing?
[07:10] <Kamion> should be /lib/firmware/ surely?
[07:10] <Keybuk> elmo: we don't use /usr/lib/firmware/$(uname -r) ? :p
[07:10] <Kamion> it's not Ubuntu-*specific* but I don't think it'll work everywhere
[07:10] <elmo> err, yeah, s#/usr##
[07:11] <elmo> Kamion: hmm, ok, just not sure where this vanilla kernel I built is looking for it's firmware, /lib/firmware/$(uname -r) isn't working
[07:11] <elmo> and Debian seems to use unversioned /lib/firmware
[07:11] <Keybuk> right
[07:11] <Keybuk> /lib/firmware is "universal"
[07:11] <Keybuk> and is the place documentation should tell users to put firmware
[07:12] <Keybuk> /lib/firmware/$(uname -r) is a "popular" place for distributors to put per-kernel-image firmware
[07:12] <Keybuk> we use both, with preference in that order
[07:12] <elmo> ah, I see, thanks
[07:14] <mjg59> jdub: Thanks for that, fixed
[07:14] <tkamppeter> pitti, have a look at http://www.freestandards.org/~till/tmp/ubuntu/usbext.h, it is the io/hpiod/usbext.h file of HPLIP 1.6.7
[07:14] <jdub> mjg59: you rock :)
[07:14] <pitti> tkamppeter: idea about what? the kernel #include?
[07:15] <zul> pitti: compiler.h is just an empty file in dapper and it doesnt exist in edgy so removing it from the header file should be fine
[07:15] <pitti> tkamppeter: ^ so, small patch to remove the #include should work then :)
[07:16] <tkamppeter> Thanks, zul, I will try it.
[07:16] <Keybuk> /usr/lib/hotplug/firmware/$(uname -r) is a historical, and very silly, firmware location
[07:16] <zul> tkamppeter: nop
[07:16] <Keybuk> I stopped supporting that for edgy, iirc
[07:19] <mdz> LaserJock: yes?
[07:20] <dholbach> have a nice weekend
[07:22] <simira> dholbach: you too. Hug your dog from me also :)
[07:22] <dholbach> simira: I'll do that!
[07:22] <rodarvus> Keybuk, yes?
[07:23] <LaserJock> mdz: pm, if you didn't see it already
[07:27] <mjg59> Kamion: I can't find any mention of 915resolution on ubuntu-bugs
[07:28] <Keybuk> rodarvus: s'ok, contacted upstream directly
[07:28] <tkamppeter> pitti, zul: Build of HPLIP has worked with this patch.
[07:29] <Kamion> mjg59: me neither; I blame Mr. Scott James "Auto-Sync" Remnant
[07:31] <Keybuk> blame me for?
[07:31] <mjg59> Keybuk: 915resolution got synced, dropping Ubuntu changes
[07:32] <Keybuk> mjg59: interesting
[07:32] <Kamion> and the creator of the sync was "Ubuntu Archive Auto-Sync"
[07:32] <Keybuk> that wouldn't have been caused by an auto-sync though
[07:32] <Keybuk> it had XubuntuY in its version
[07:32] <Keybuk> 2006-07-06 04:07:34 BST  	Published  	edgy   	Release  	universe  	x11  	0.5.2-4
[07:32] <Keybuk> 2006-06-08 15:44:14 BST 	Removed 	edgy 	Release 	universe 	x11 	0.5-1ubuntu6
[07:32] <Keybuk> somebody removed it from edgy
[07:33] <mjg59> Any way of tracking who?
[07:33] <Keybuk> oh, hmm, that may be LP's new way of saying superseded
[07:33] <Keybuk> grr
[07:34] <Kamion> isn't that "superseded *and* we've actually purged it from disk?"
[07:35] <Kamion> er s/\?"/"?/ logical quoting damnit
[07:35] <elmo> hmm, does request_firmware() work for compiled in drivers?
[07:37] <Keybuk> elmo: should do
[07:38] <Keybuk> Kamion: ya know, I've no idea why this got sync'd
[07:38] <Keybuk> the auto-sync always refuses to do XubuntuY
[07:38] <Keybuk> if I forced them, they'd show up as "keybuk"
[07:38] <Kamion> somebody didn't use -b auto -f?
[07:38] <Kamion> er -b katie -f
[07:38] <Kamion> whatever the launchpad user id is
[07:38] <Keybuk> wouldn't have been me
[07:39] <Kamion> whoever it was it's probably lost in expired .bash_history
[07:39] <Kamion> mjg59: upshot is, we have no clue. sorry.
[07:39] <Keybuk> yeah, and long lost from wtmp
[07:39] <Keybuk> it won't have been a sync-request either
[07:39] <Keybuk> the fact that the remove and publish are _so_far_ apart is very suspicious
[07:39] <Keybuk> that really really really suggests to me that it was removed from edgy
[07:39] <Keybuk> and the sync copied it as a new source
[07:40] <Keybuk> it's not in removals.txt though
[07:40] <Keybuk> oh, interesting
[07:40] <Keybuk> it utterly FTFBS in edgy
[07:40] <Keybuk> maybe someone removed the source by accident
[07:40] <Keybuk> when they were trying to remove a bad binary
[07:41] <Kamion> archive-cruft-check or something?
[07:41] <Kamion> because that's the only thing that doesn't log
[07:41] <Keybuk> yeah, could be that
[07:41] <Kamion> and that would have removed a *ton* of stuff, probably
[07:41] <Keybuk> 15:44 BST ... far too early for me to have been up :p
[07:41] <Kamion> and in fact it would never have removed source
[07:41] <Kamion> so it wasn't that
[07:41] <Kamion> remove-package.py plus vi removals.txt? ;-)
[07:41] <Keybuk> 06-08 was very very early in edgy?
[07:42] <Kamion> that was definitely when you were driving all syncs
[07:42] <Keybuk> no, I wasn't driving syncs until quite a bit after that
[07:42] <mjg59> Keybuk: Seems to build fine here
[07:42] <Kamion> I didn't start touching them until after Paris
[07:42] <Keybuk> 08 was the day we managed to get edgy open!
[07:42] <mjg59> It'd be nice to know what happened so I can check that nothing else has been hit, but...
[07:43] <Kamion> don't remember doing removals that early in the cycle
[07:43] <Keybuk> no, that was still toolchain churn
[07:43] <Keybuk> I literally mean that was the day we added edgy to launchpad
[07:43] <Kamion> it only FTBFS on non-x86 arches
[07:43] <Kamion> which is fair enough, really
[07:43] <mjg59> It should only be built for i386 and amd64
[07:43] <Keybuk> Kamion: there's no non-x86 build record at all
[07:43] <Keybuk> I reckon that this somehow ended up in the build queue when edgy was opened
[07:43] <Kamion> Keybuk: sure there is, see https://launchpad.net/distros/ubuntu/+source/915resolution/0.5.2-4
[07:44] <Keybuk> before there was a stable toolchain
[07:44] <Kamion> https://launchpad.net/+builds/+build/222706
[07:44] <Keybuk> Kamion: no, I mean the one that was removed
[07:44] <Keybuk> https://launchpad.net/distros/ubuntu/+source/915resolution/0.5-1ubuntu6
[07:44] <Keybuk> there's no build record for x86
[07:44] <Kamion> oh, I see
[07:44] <Kamion> we probably automatically retried everything that FTBFS in edgy as soon as edgy opened
[07:44] <Keybuk> so yeah, I reckon this ended up in the build queue when edgy was opened by accident or by soyuz bug, it didn't get built on three and never even got a build record on the rest
[07:44] <Kamion> no, it's deliberate
[07:45] <Keybuk> and somebody tried to remove it and hide the evidence
[07:45] <Keybuk> no, we didn't
[07:45] <Kamion> as soon as there's a new distrorelease there, it retries everything from the last one
[07:45] <Keybuk> we waited until we built the toolchain :)
[07:45] <Keybuk> this is before we had a toolchain judging by -changes
[07:45] <Kamion> *we* didn't, but soyuz didn't know that ...
[07:45] <Keybuk> ahh
[07:45] <Kamion> nobody told it to stop building stuff :)
[07:45] <Keybuk> so yeah, looks like someone accidentally removed a source when they were trying to just remove the binaries, or something
[07:45] <Kamion> we just stopped all source from going through
[07:45] <Kamion> mm, seems probable
[07:45] <Keybuk> this is all guessing, of course
[07:45] <mjg59> It'd be nice if there was an audit trail for this stuff
[07:46] <Keybuk> and then a month later, when I was doing auto-syncs, the new version came in
[07:46] <Keybuk> mjg59: there is, kinda
[07:46] <mjg59> Keybuk: Well, not in this case :)
[07:46] <Keybuk> the trouble is the answer to "who did that" is always lp_archive
[07:46] <Kamion> we only know this much because there is an audit trail - it's just incomplete
[07:46] <Kamion> relevantly - what Keybuk said
[07:46] <mjg59> Right
[07:46] <Kamion> it's pretty bogus that we have to sudo to lp_archive to do anything, really
[07:47] <Kamion> but it'll all be fixed once it's all done through the launchpad web UI, I guess
[07:47] <mjg59> Wouldn't the sudo stuff be logged?
[07:47] <Keybuk> there's nothing in removals.txt from 31st May to 21st Jun
[07:47] <Kamion> mjg59: we generally sudo -i
[07:47] <Keybuk> which about fits with the "opening edgy" delay
[07:47] <Kamion> so not usefully
[07:47] <Keybuk> mjg59: we don't have logs of that far back :-/
[07:47] <mjg59> Kamion: Right, but you'd... ah, never mind
[07:48] <Keybuk> anyway, given the timings, I would say it was the combination of human and computer error during the edgy opening
[07:48] <mjg59> Yeah
[07:49] <mjg59> It's unfortunate that it took jdub bitching about something I was sure I'd fixed to notice it, though...
[07:50] <jdub> :(
[07:50] <jdub> <- not a bitch
[07:50] <zul> lol
[07:50] <bddebian> heh
[07:58] <rizo> is knot3 different from yesterday's daily iso?
[07:59] <elmo> Keybuk: (btw, fyi, request_firmware doesn't work when you're totally modularless - apparently it might if you introduce initramfs, but otherwise the drivers run reuqest_firmware too early)
[08:01] <Kamion> rizo: it'll be the same as the current daily images
[08:03] <Keybuk> elmo: well, duh :p
[08:04] <tkamppeter> pitti, I am currently uploading the new HPLIP packages to http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/
[08:04] <tkamppeter> and the binaries to http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/binary/
[08:06] <tkamppeter> pitti, but I have still a problem: On my system is the old hpijs-ppds and hpijs installed, when I do "sudo dpkg -i hpijs*.deb" to update both to the new package, I get an error because the new hpijs-ppds conflicts with the old one.
[08:07] <tkamppeter> Usually a new package should simply replace the old one.
[08:07] <Kamion> if you move files from one package to another, you must include a suitable Replaces header
[08:08] <Kamion> generally it's versioned, Replaces: package-the-files-came-from (<< first-version-of-that-package-that-doesn't-contain-the-files)
[08:08] <tkamppeter> pitti (or someone else), can you look into the control file, whether there is something wrong? I have uploaded it to http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/control
[08:09] <Kamion> tkamppeter: what exactly is the error message emitted by dpkg?
[08:10] <tkamppeter> till@laptoptill:~/ubuntu/hplip$ sudo dpkg -i hpijs*.deb
[08:10] <tkamppeter> Password:
[08:10] <tkamppeter> dpkg: regarding hpijs_2.6.7+1.6.7-2ubuntu1_i386.deb containing hpijs:
[08:10] <tkamppeter>  hpijs conflicts with hpijs-ppds (<< 2.6.7)
[08:10] <tkamppeter>   hpijs-ppds (version 2.1.10+0.9.11-2ubuntu7) is installed.
[08:10] <tkamppeter> dpkg: error processing hpijs_2.6.7+1.6.7-2ubuntu1_i386.deb (--install):
[08:10] <tkamppeter>  conflicting packages - not installing hpijs
[08:10] <tkamppeter> dpkg: regarding hpijs-ppds_2.6.7+1.6.7-2ubuntu1_all.deb containing hpijs-ppds:
[08:10] <tkamppeter>  hpijs conflicts with hpijs-ppds (>= 2.1.10.1)
[08:10] <tkamppeter>   hpijs-ppds (version 2.6.7+1.6.7-2ubuntu1) is to be installed.
[08:10] <tkamppeter> dpkg: error processing hpijs-ppds_2.6.7+1.6.7-2ubuntu1_all.deb (--install):
[08:10] <tkamppeter>  conflicting packages - not installing hpijs-ppds
[08:10] <tkamppeter> Errors were encountered while processing:
[08:10] <tkamppeter>  hpijs_2.6.7+1.6.7-2ubuntu1_i386.deb
[08:10] <tkamppeter>  hpijs-ppds_2.6.7+1.6.7-2ubuntu1_all.deb
[08:10] <tkamppeter> till@laptoptill:~/ubuntu/hplip$
[08:11] <Kamion> oh dear god, what are those Conflicts about
[08:11] <tkamppeter> There should be a way to update both at a time.
[08:11] <Kamion> tkamppeter: you can probably resolve that by using dpkg's --auto-deconfigure option
[08:12] <Kamion> apt should manage to resolve it too
[08:12] <Keybuk> elmo: module-less kernels cause sterility
[08:12] <tkamppeter> Kamion, --auto-deconfigure gives the same errors.
[08:13] <tkamppeter> Kamion, who can I install packages in local files with apt?
[08:13] <Kamion> no, wait
[08:13] <Kamion> don't flail around just yet :)
[08:14] <Kamion> iwj could confirm, but I think it might be best to change hpijs's Conflicts to Breaks.
[08:14] <tkamppeter> "apt-get install" does not find packages in the local working directory.
[08:14] <Kamion> no, it won't.
[08:15] <Kamion> if dpkg -i --auto-deconfigure can't manage it, then the problem should be fixed, not worked around by using apt
[08:15] <tkamppeter> What is the difference between Conflicts and Breaks? Why does it work on Debian?
[08:15] <Kamion> at present, the relationships declared by those packages are such that hpijs must be removed during upgrades to a new upstream version.
[08:15] <Kamion> or possibly hpijs-ppds - one of the two
[08:16] <Kamion> this "works" with apt (and therefore you probably haven't noticed the problems on Debian) because it will just remove one of them temporarily
[08:16] <Kamion> however, this causes a lot of problems, such as inadvertent removal of metapackages and future upgrade problems
[08:16] <Kamion> Conflicts means that the two packages cannot exist on the system *at all* (even just unpacked) at the same time
[08:16] <Kamion> Breaks means that the two packages can't both be simultaneously in the "configured" state
[08:17] <Kamion> therefore, Breaks would allow --auto-deconfigure to work in this case; dpkg would be able to temporarily deconfigure one of the packages, install the other, and then install the new version of the deconfigured package
[08:17] <Kamion> (and configure it)
[08:18] <Kamion> Breaks is a recent innovation (it was designed nearly a decade ago, but only recently implemented by iwj), so you probably won't find it in Debian
[08:20] <Kamion> tkamppeter: but, as I say, consult with iwj; he's currently in charge of Breaks deployment
[08:24] <tkamppeter> Kamion, yes, that's it! I have put "Breaks:" now and I can update with "--auto-deconfigure". Thank you very much.
[08:25] <Kamion> good
[08:26] <tkamppeter> Kamion, pitti, zul: Uploading all packages to the place I already mentioned, overwriting my previous packages.
[08:28] <tkamppeter> Kamion, pitti, zul: The source packages and the control file are ready on http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/
[08:28] <tkamppeter> So ready for everyone to test and for final upload afterwards.
[08:30] <tkamppeter> And for quick testing on 32-bit PCs, here are the binaries: http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/binary/
[08:35] <iwj> Kamion: The effect of Breaks nowadays is to defer upgrade of the breaking package until the broken one is upgraded so that it won't be broken.
[08:35] <iwj> OIC.
[08:36] <Kamion> the relevant relationship field was:
[08:36] <Kamion> Package: hpijs
[08:36] <Kamion> Conflicts: hplip-ppds (<< ${Source-Version}), hpijs-ppds (<< ${hpijs:Upstream-Version}), hpijs-ppds (>= ${hpijs:Upstream-Version}.1)
[08:36] <iwj> tkamppeter: Yes, that should be Breaks.
[08:36] <iwj> It's also quite crazy.
[08:36] <iwj> I mean, WTF ?
[08:37] <Kamion> I don't understand why it isn't just a Depends, but I never did understand the maze of twisty printing packages
[08:37] <Kamion> presumably it's in some sense optional, but ...
[08:38] <Kamion> iwj: thus the problem was that one of them *has* to be deconfigured when upgrading to a new upstream version, even with Breaks
[08:38] <Kamion> since installed-hpijs Breaks: new-hpijs-ppds and new-hpijs Breaks: installed-hpijs-ppds
[08:39] <iwj> Yes.  It's very strange that this isn't a Depends.
[08:39] <tkamppeter> So then all is OK now, If no one sees any problem when running the new HPLIP we can upload my version to to Edgy.
[08:39] <iwj> But certainly Conflicts is wrong.
[08:39] <iwj> Did you change it to Breaks ?
[08:40] <Kamion> mvo: do you have any idea what happened to your GST_NO_INSTALL_NTP patch? it appears to have disappeared from gnome-system-tools
[08:40] <tkamppeter> Yes, my uploaded packages have it changed to Breaks.
[08:40] <Kamion> mvo: there's some argument that the exact form of that patch should be changed anyway (see bug 52718) but it needs to be reinstated first :)
[08:40] <Ubugtu> Malone bug 52718 in ubiquity "Unable to activate NTP support in the installer because it's not installed (?!)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52718
[08:41] <mvo> Kamion: no, I guess it was a merge mistake of some sort, let me have a look
[08:41] <iwj> tkamppeter: Excellent.
[08:41] <mvo> Kamion: let me check the changelogs
[08:43] <Kamion> I've reassigned 52718 to gnome-system-tools, if you want to subscribe to it
[08:44] <mvo> Kamion: done, thanks
[08:45] <iwj> I'm really going to quit for the weekend now and have some dinner.  Have a good time, everyone.
[08:46] <zul> later iwj
[08:51] <jdong> bye, iwj... thanks for new firefox packages :)
[08:57] <KhanReaper> Hi, I saw something in a debian/rules file, and it confused me. Can someone tell me why clean calls "-$(MAKE) clean," specifically why $(MAKE) is prefixed with a "-"?
[09:00] <mvo> Kamion: eh, am I missing something? in dapper we apparently have 2.14.0-0ubuntu11 and that one seems to include the GST_NO_INSTALL_NTP patch
[09:01] <mvo> Kamion: or is the bugreport about edgy? 
[09:03] <Kamion> mvo: the bug report is probably about dapper, where he's saying that the problem is that the rest of the NTP UI is still visible even though the "Install NTP support" button is disabled
[09:03] <Kamion> mvo: I'm talking about edgy, though
[09:03] <ogra> urgh
[09:04] <Kamion> KhanReaper: "-" in a Makefile means "ignore errors from this command". It's often used in clean rules because you don't care if the Makefile happens to have been removed already or something like that.
[09:04] <ogra> was that dropped intentional ?
[09:04] <ogra> rodarvus, ?? ^^^
[09:05] <rodarvus> ogra, no, nothing intentional happened there
[09:05] <rodarvus> ogra, is this causing you (or someone else) any problem?
[09:06] <ogra> yep
[09:06] <mvo> Kamion: aha, ok
[09:06] <ogra> we're just trying to boot a ltsp 170 terminal from disklessworkstations.com ... it needs a forced videoram oarameter of 16384 
[09:06] <ogra> *parameter
[09:07] <ogra> but due to the missing preseedability i cant set it
[09:07] <rodarvus> ogra, I would say its probably something inherited from debian when upgrading xorg from 7.0 to 7.0.22
[09:08] <ogra> yep
[09:08] <ogra> i know we had that parameter in the postinst, its not there anymore in the current package
[09:14] <jdong> tseng: now that mono-xsp works, is our monodevelop being built with asp.net designer support?
[09:14] <tseng> jdong: not that I know of
[09:14] <jdong> tseng: any reason why we don't?
[09:14] <tseng> xsp is priority 423456 for any one currently on the mono team
[09:14] <tseng> if you care for it debdiffs are much appreciated
[09:14] <jdong> tseng: I noticed a new mono-xsp upload to match 1.1.17, though
[09:15] <tseng> yes to make it installable
[09:15] <jdong> tseng: all it takes to build monodevelop against it is --enable-asp.net-designer or something like that in ./configure
[09:15] <tseng> we try not to completely neglect it
[09:15] <tseng> as in, leave it uninstallable
[09:16] <tseng> we cant confirm bugs, or things like, hey, this xsp-monodevelop thing is legit
[09:16] <tseng> I doubt just passing the configure flag is sufficient
[09:16] <tseng> I don't want installing monodevelop to pull down xsp2 to everyone
[09:17] <tseng> it needs split packaging, auditing on every release that it doesnt  have new, renamed, removed filed
[09:17] <jdong> I see
[09:17] <jdong> that's true, forgot about split-out packages
[09:17] <tseng> keeping in mind that none of us want to touch xsp with a 10-foot pole
[09:17] <jdong> hehe, monodevelop 0.12 doesn't compile from source :)
[09:19] <tseng> we have a cvs snapshot
[09:20] <jdong> tseng: slomo just uploaded a 0.12 this morning
[09:21] <tseng> cool
[09:21] <jdong> and apparently it doesn't build :)
[09:21] <jdong> hehe
[09:22] <tseng> Addin.cs(280,23): error CS0102: The type `VersionControlPlugin.BaseView' already contains a definition for `StockIconId'
[09:26] <tseng> you are a C# guy, bet thats an easy fix
[09:47] <neuralis> jdub: around?
[09:56] <mjg59> Seveas: usplash appears horribly broken at 640x480
[09:56] <Seveas> mjg59, -25 fixes that
[09:57] <Seveas> none of the default themes have a 640x480 version
[09:57] <jordi> muh
[09:57] <jordi> pitti's gone
[09:57] <mjg59> Seveas: Ahhhh
[09:58] <mjg59> Seveas: They really should, since that's what's going to be used for first boot
[09:58] <Seveas> mjg59, I'll tell the artwork people
[09:58] <mjg59> Uh. Or does usplash default to 1024x768 if there's no arguments?
[09:59] <Seveas> no, 640x480
[09:59] <mjg59> Ok, cool
[09:59] <Seveas> but it didn't check whether the theme was suitable for it
[10:00] <Seveas> so it tried to use the 800x600 one for 640x480
[10:00] <mjg59> The livecd is going to start usplash before there's any X config done
[10:00] <mjg59> Seveas: Hm. No, if I run usplash on its own, I get a high-res image
[10:00] <mjg59> If I do usplash -x 640 -y 480, I get a "No theme found" error
[10:01] <Seveas> right, sorry, with no -x and -y, it'll pick the first theme and use its resolution
[10:01] <mjg59> Seveas: Right. It needs to default to 640x480.
[10:01] <Seveas> but livecds should have an /etc/usplash.conf, n'est-ce pas?
[10:01] <mjg59> Seveas: How?
[10:01] <sladen> mjg59: I think it'd quite safe to assume 800x600x8.  Microsoft have mandated it for logo requirements since 1999
[10:02] <Seveas> I don't know the details of th buildprocess, but aren't the postinst scripts run?
[10:02] <mjg59> sladen: We still run on older hardware
[10:02] <Seveas> usplash' postinst will write it
[10:02] <mjg59> Seveas: Yeah, but I thought they defaulted to blank
[10:02] <mjg59> Oh, no, ok
[10:02] <mjg59> You're right
[10:02] <Seveas> I *thought* 640x480, but will check to make sure
[10:02] <mjg59> Yeah, they're the default values
[10:02] <sladen> mjg59: we don't.  Our kernel won't boot with less than 64MB of RAM...
[10:03] <mjg59> sladen: There are laptops that are expandable past that but which have worse screens
[10:03] <Seveas> mjg59, I just doublechecked, it defaults to 640x480
[10:04] <mjg59> Seveas: Yeah
[10:04] <mjg59> Sorry, my error
[10:07] <ogra> crimsun, ping ? 
[10:15] <mdz> mjg59: hmm, in fact we should add an explicit removal of usplash.conf to the live CD build process, otherwise it'll reflect the X configuration on the DC server
[10:16] <mdz> or else regenerate it from casper
[10:18] <mjg59> mdz: I think kamion's already dealt with that
[10:23] <mdz> mjg59: which way?
[10:23] <jdong> Kamion: can you push libtorrent7* through dapper-backports NEW?
[10:23] <jdong> or is soyuz still being mean to me :)
[10:24] <mjg59> mdz: Regenerating it after install
[10:38] <Kamion> mdz: I made ubiquity do rm -f /target/etc/usplash.conf; chroot /target dpkg-reconfigure usplash
[10:38] <Kamion> (effectively)
[10:38] <Kamion> haven't uploaded that yet though, it's still in bzr
[10:39] <Kamion> jdong: soyuz still doesn't like backports, afaik
[10:39] <Kamion> sladen: perhaps it's changed recently, but I tested the dapper installer all the way through with 32MB
[10:39] <jdong> heh, wonderfull.... any idea when that'll be resolved?
[10:39] <jdong> I'm sitting here waiting, and it doesn't look like there's been any work towards it
[10:40] <Kamion> jdong: dunno, but it's critical/in-progress
[10:40] <jdong> Kamion: yeah, and it has sat there silently in that stage for weeks now
[10:40] <Kamion> it's just awaiting a merge I think
[10:40] <Kamion> LP merge timescales are often quite long unfortunately
[10:40] <Kamion> since they involve review
[10:40] <jdong> :-/
[10:42] <Kamion> mdz: any chance you could chase up the flow of bug 58144 into production?
[10:42] <Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,In progress]  http://launchpad.net/bugs/58144
[10:42] <Kamion> mdz: I haven't had a chance to get a consensus on the "central issue" referred to by cprov, but that is not necessary to get the immediate fix into production
[10:47] <kagou> iwj, still have problem with fontconfig-config. "dpkg-reconfigure --default-priority" make a 30-debconf-yes-bitmaps"
[10:48] <kenne> anyone know when the libjingle and farsight libraries will be in edgy
[10:51] <mdz> Kamion,mjg59: regenerating it after install is good but orthogonal; I"m talking about th econfiguration used during the livecd boot
[10:52] <mjg59> mdz: The default file contains 640x480
[10:52] <mdz> mjg59: oh, i thought it magicked it based on the xorg config
[10:52] <mjg59> Yes, but in the livecd case there won't have been an xorg config for it to have magiced it from
[10:52] <mjg59> So it'll fall back to the defaults
[10:53] <mdz> Kamion: re: backports, will do
[10:53] <Kamion> mdz: thanks
[10:53] <mdz> mjg59: oh?  I would expect usplash and xorg to be installed in the same batch
[10:53] <Kamion> usplash doesn't depend on xserver-xorg
[10:54] <mdz> Kamion: yeah, but they're both part of desktop
[10:54] <Kamion> so it's not guaranteed to be installed first
[10:54] <Kamion> er, second
[10:54] <mdz> xorg may or may not be configured first
[10:54] <Kamion> it usually won't
[10:54] <mjg59> mdz: usplash will be started some time before xorg is configured, surely?
[10:54] <Kamion> usplash's dependencies are simpler so apt/dpkg tend to get to them first
[10:54] <mdz> mjg59: it gets configured twice, once on the buildds and then reconfigured at boot
[10:54] <mjg59> mdz: Right, but it's run out of the initramfs
[10:54] <Kamion> mdz: at boot, usplash is started before xorg is reconfigured
[10:54] <mdz> correct
[10:55] <mdz> thus, it's using the config supplied by the buildd
[10:55] <Kamion> right ...
[10:55] <mjg59> Right. Which will be 640x480.
[10:55] <mdz> which happens to be 640x480, but we should probably make it explicit
[10:55] <elmo> mjg59: what makes you think that, JOOI?
[10:55] <elmo> these things have KVMs attached
[10:55] <mjg59> elmo: Hm.
[10:55] <mdz> elmo: because usplash tends to be configured before xorg is, and xorg defaults to 640x480 I think
[10:56] <Kamion> right, just what I was typing
[10:56] <mdz> luck really
[10:56] <Kamion> although actually not quite
[10:56] <Kamion> if xorg hasn't been configured yet, then usplash explicitly says "ok, I'll use 640x480 then"
[10:56] <mjg59> The ordering should possibly be enforced, but other than that things seem to work as designed
[10:56] <Kamion> but same difference
[10:56] <elmo> ok, if that's the reason.  but if you were expecting it because they're buildds in a DC, I just wanted to point out that they do actually all have a "monitor" and don't run in 640x480
[10:56] <Kamion> mjg59: we don't want to enforce that ordering
[10:56] <Kamion> at least not under normal circumstances
[10:57] <Kamion> mjg59: because in d-i, we want to arrange for precisely the reverse ordering - xserver-xorg then usplash
[10:57] <mjg59> Kamion: Yeah
[10:57] <Kamion> I'm working on that
[10:57] <Kamion> I'm going to do that by adding xserver-xorg to the list of packages installed up-front in tasksel's desktop.preinst
[10:58] <Kamion> getting decent progress output out of that requires a bit of fiddling, so it's not a one-line fix, but I understand the problem
[10:59] <Kamion> anyway, yeah, possibly casper should blat in a 640x480 configuration
[10:59] <Kamion> I'd rather that sort of thing be done in casper than in the live CD build, personally
[11:00] <mdz> I sent an email about this
[11:00] <Kamion> actually, further to that, maybe it shouldn't force 640x480 either
[11:00] <Kamion> on my powerbook's panel, for instance, it should just use the native resolution
[11:00] <Kamion> i.e. don't change modes at all
[11:00] <mjg59> Kamion: Right, the alternative is to fail to pass any parameters
[11:01] <mjg59> If usplash.conf doesn't exist
[11:01] <Kamion> yeah. what does the SVGA backend do with that?
[11:01] <mjg59> Uses 640x480
[11:01] <mjg59> Which currently breaks due to the lack of 640x480 artwork, but still
[11:01] <Kamion> ok, ideal, since BOGL uses whatever the current mode is
[11:01] <Kamion> yeah, that's clearly an artwork bug
[11:02] <mjg59> The usplash init script just needs modifying to deal with that case
[11:02] <mjg59> Or set them both to 0
[11:02] <Kamion> I'll do that now
[11:02] <Kamion> just rming it seems simpler
[11:03] <mjg59> Yeah, the init script doesn't currently deal with that case
[11:04] <mdz> mjg59: which defaults were changed in acpi-support and what were they changed to?
[11:05] <Kamion> mjg59: what's the reason for the sleep 1 at the end of the usplash initramfs script?
[11:06] <mjg59> Kamion: Erm.
[11:06] <mjg59> Kamion: No idea at all. Feel free to kill it.
[11:06] <mjg59> mdz: Sleep and DPMS
[11:06] <mjg59> DPMS was disabled for hibernation, sleep was enabled globally.
[11:10] <ogra> roddarvus, ping 
[11:10] <ogra> hrm ... gone ...
[11:11] <mjg59> uswsusp works surprisingly nicely
[11:11] <mjg59> I think we can default to it in edgy+1
[11:11] <mjg59> Graphical suspend/resume feedback, and faster than the standard kernel stuff
[11:11] <Kamion> I'll commit the usplash initramfs fixes, just need to cope with one-second ping times to my ISP. gn.
[11:14] <Kamion> mjg59: did you upload 0.4-26? it's not UNRELEASED, but I don't see it in -changes
[11:14] <mdz> mjg59: baby jesus prefers more informative changelog entries ;-)
[11:14] <mjg59> Kamion: Pretty sure I did...
[11:14] <mjg59> mdz: Sure
[11:14] <mjg59> Kamion: But possible that I didn't
[11:14] <madduck> buzzen: this is a bug Ubuntu should fix before the release. please file a bug in launchpad and ask them to disable the stop call in preinst.
[11:14] <mjg59> Let me check
[11:15] <madduck> buzzen: they can check how i did it in mdadm 2.5 in debian
[11:15] <Kamion> I don't see it on drescher anywhere
[11:16] <Kamion> mjg59: if you didn't, can I sneak my change into it? :)
[11:17] <Lure> mjg59: how do you enable hibernate with s2disk? just install uswsusp package?
[11:17] <mjg59> Kamion: Looks like I didn't, so feel free
[11:17] <mjg59> Lure: Correct
[11:18] <mjg59> You'll need to wait for 0.2.1, which won't get build until the new usplash gets uploaded
[11:18] <Lure> mjg59: ok, will do